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SUMMARY 


Under  previous  efforts,  Armstrong  Laboratory  developed  two  human  models, 
COMBIMAN  and  CREW  CHIEF.  CREW  CHIEF  is  a  computer  model  of  an  Air  Force 
maintenance  technician,  and  may  be  used  to  evaluate  maintainability  of  aircraft,  as  well  as 
equipment  in  general.  COMBIMAN  is  a  computer  model  of  an  aircraft  pilot,  and  may  be  used  to 
evaluate  cockpit  accommodation,  as  well  as  accommodation  for  a  seated  operator,  in  general. 
Both  models  are  interfaced  directly  to  commercial  CAD  systems,  and  execute  as  third-party 
applications  under  these  CAD  systems. 

CREW  CHIEF  simulates  the  non-trivial  physical  activities  of  the  Air  Force  maintenance 
technician,  including  working  with  hand  tools,  hand  controls,  and  manual  materials  handling 
activities  in  various  postures.  These  activities  are  modeled  as  a  function  of  body  size,  strength, 
and  encumbering  personal  protective  equipment.  Special  attention  is  given  to  the  evaluation  of 
visual  and  physical  accessibility  of  the  system  being  maintained.  The  question  answered  by  the 
CREW  CHIEF  model  is  "Can  the  maintenance  technician  perform  a  specified  physical  activity?" 

COMBIMAN  simulates  the  non-trivial  physical  activities  of  an  Air  Force  pilot  or,  more 
generally,  of  a  seated  operator,  and  include  such  activities  as  reaching  and  actuating  aircraft 
controls,  in-flight  ejections,  and  monitoring  read-outs  and  displays  in  the  cockpit.  Similar  to 
CREW  CHIEF,  the  emphasis  of  a  COMBIMAN  analysis  is  on  physical  and  visual  accessibility. 

These  computer  models  are  CAE  tools  used  by  a  designer  to  evaluate  some  aspect  of 
human  physical  performance.  The  object  of  the  analysis-  the  aircraft  or  cockpit  being  analyzed- 
is  usually  in  the  preliminary  design  phase,  which  is  to  say,  that  it  is  still  "on  the  drawing  board," 
and  does  not  yet  exist  in  a  prototype  form.  By  performing  such  human  factors  in  this  phase  of 
development,  designers  have  more  latitude  to  make  meaningful  changes  to  improve  ergonomics  in 
their  designs,  as  opposed  to  waiting  until  a  prototype  exists,  and  even  minimal  changes  become 
much  more  costly. 

The  work  on  this  contract  relates  to  enhancements  to,  support  for,  and  additional  data 
collection  for  these  two  computer  models.  Some  of  the  enhancements  were  dictated  by  the 
Statement  of  Work  (SOW),  while  others  were  developed  based  on  input  from  current  users. 
Support  includes  such  things  as  software  management,  distribution,  and  promotion.  And  human 
physical  performance  data  were  collected  in  support  of  enhancements  or  to  refine  existing  data 
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models  used  in  COMBIMAN  or  CREW  CHIEF.  Section  1  gives  an  executive  overview  of  the 
final  report.  Section  2  describes  the  enhancement  and  update  of  CREW  CHIEF.  Section  3 
describes  the  enhancement  and  update  of  COMBIMAN.  Section  4  discusses  the  general  support 
to  software  development.  Section  5  discusses  the  ergonomics  research. 
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SECTION  I  -  INTRODUCTION 


U  S.  Air  Force  contract  F33615-89-C-0575,  "Computer  Models  for  Ergonomics,"  was 
issued  for  exploratory  development  and  research  to  enhance  maintainability  and  workstation 
effectiveness  of  future  Air  Force  weapons  systems  through  the  application  of  biomechanical 
engineering  data  and  techniques.  The  research  aspect  of  this  effort  was  the  expansion  of  the 
databases  describing  maintenance  technician  and  crew  member  limitations,  such  as  physical 
strength  and  endurance  characteristics  of  male  and  female  Air  Force  workers;  body  size 
limitations  for  fit  and  reach  accommodation;  limitations  on  tool  and  equipment  manipulations 
due  to  restricted  workplaces;  personal  protective  equipment  and  clothing  (including 
appropriate  space  suits  and  clothing);  visual  degradation  due  to  personal  protective  equipment 
and  restricted  workplaces;  and  the  duration  of  manual  activities.  The  development  aspect  of 
this  effort  included  enhancements  to  computer  models  of  the  maintenance  technician  and  air 
crew  members;  the  creation  of  data  models  and  algorithms  relating  these  ergonomic 
limitations  and  capabilities  to  specifications  for  weapon  system  maintainability;  design 
specifications,  standards  and  handbooks;  and  the  creations  of  Computer-aided  Engineering 
(CAE)  software  tools  to  support  design,  evaluation,  source  selection,  and  trade-of  studies  for 
system  acquisition. 


1.1  Background 

Under  previous  efforts,  Armstrong  Laboratory  developed  two  human  models, 
COMBIMAN  and  CREW  CHIEF.  CREW  CHIEF  is  a  computer  model  of  an  Air  Force 
maintenance  technician,  and  may  be  used  to  evaluate  maintainability  of  aircraft,  as  well  as 
equipment  in  general.  COMBIMAN  is  a  computer  model  of  an  aircraft  pilot,  and  may  be  used 
to  evaluate  cockpit  accommodation,  as  well  as  accommodation  for  a  seated  operator,  in 
general.  Both  models  are  interfaced  directly  to  commercial  CAD  systems,  and  execute  as 
third-party  applications  under  these  CAD  systems. 

CREW  CHIEF  simulates  the  non-trivial  physical  activities  of  the  Air  Force 
maintenance  technician,  including  working  with  hand  tools,  hand  controls,  and  manual 
materials  handling  activities  in  various  postures.  These  activities  are  modeled  as  a  function  of 
body  size,  strength,  and  encumbering  personal  protective  equipment.  Special  attention  is 
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given  to  the  evaluation  of  visual  and  physical  accessibility  of  the  system  being  maintained. 

The  question  answered  by  the  CREW  CHIEF  model  is  "Can  the  maintenance  technician 
perform  a  specified  physical  activity?" 

COMBIMAN  simulates  the  non-trivial  physical  activities  of  an  Air  Force  pilot  or, 
more  generally,  of  a  seated  operator,  and  include  such  activities  as  reaching  and  actuating 
aircraft  controls,  in-flight  ejections,  and  monitoring  read-outs  and  displays  in  the  cockpit. 
Similar  to  CREW  CHIEF,  the  emphasis  of  a  COMBIMAN  analysis  is  on  physical  and  visual 
accessibility. 

These  computer  models  are  CAE  tools  used  by  a  designer  to  evaluate  some  aspect  of 
human  physical  performance.  The  object  of  the  analysis—  the  aircraft  or  cockpit  being 
analyzed—  is  usually  in  the  preliminary  design  phase,  which  is  to  say,  that  it  is  still  "on  the 
drawing  board,"  and  does  not  yet  exist  in  a  prototype  form.  By  performing  such  human 
factors  in  this  phase  of  development,  designers  have  more  latitude  to  make  meaningful 
changes  to  improve  ergonomics  in  their  designs,  as  opposed  to  waiting  until  a  prototype 
exists,  and  even  minimal  changes  become  much  more  costly. 

The  work  on  this  contract  relates  to  enhancements  to,  support  for,  and  additional  data 
collection  for  these  two  computer  models.  Some  of  the  enhancements  were  dictated  by  the 
Statement  of  Work  (SOW),  while  others  were  developed  based  on  input  from  current  users. 
Support  includes  such  things  as  software  management,  distribution,  and  promotion.  And 
human  physical  performance  data  were  collected  in  support  of  enhancements  or  to  refine 
existing  data  models  used  in  COMBIMAN  or  CREW  CHIEF. 

1.2  Enhance  and  Update  CREW  CHIEF 

Over  the  course  of  the  previous  contract,  CREW  CHIEF  users  and  potential  users 
were  surveyed  and  questioned  concerning  enhancements  to  the  CREW  CHIEF  model  that 
they  would  find  useful.  The  two  major  enhancements  most  often  cited  by  these  customers 
called  for  explicitly  in  the  contract.  In  addition,  since  CREW  CHIEF  interacts  directly  with 
commercial  CAD  systems  and  databases,  customers  were  queried  concerning  their  current  and 
projected  CAD  development  platforms,  with  the  intention  of  porting  the  CREW  CHIEF 
model  to  those  particular  platforms.  During  this  contract,  versions  3  and  4  of  CREW  CHIEF 
were  released. 


2 


Since  the  Air  Force  is  beginning  to  require  that  weapons  systems  manufacturers 
consider  maintenance  times  in  their  designs,  and  since  no  method  existed  for  the  accurate  and 
standard  estimation  of  these  times,  the  single  most  requested  enhancement  to  the  CREW 
CHIEF  model  was  the  development  of  an  objective  Time-to-Repair  estimation  capability. 

Most  of  the  experimentation  performed  under  this  contract  went  towards  collecting  data  to 
support  development  of  this  capability.  Even  so,  because  of  the  immense  quantity  of  data 
required,  and  because  of  unexpected  funding  cuts  experienced  throughout  the  life  of  the 
contract,  not  all  aspects  of  this  capability  were  fully  developed  under  this  contract.  An  initial 
capability  was  developed,  with  some  time  estimation  capabilities.  However,  there  are  still  data 
needed  in  particular  areas;  and  flight-line  validation  was  not  possible  under  this  effort. 

With  the  construction  of  the  Space  Station  Freedom,  and  as  people  venture  further  out 
into  space  for  more  extended  periods  of  time,  equipment  will,  of  necessity,  become  more 
reusable,  and  extra-  and  intra-vehicular  maintenance  activities  will  become  more  prevalent. 
Consequently,  designers  need  to  begin  to  consider  human  physical  capabilities  in  space,  and 
the  way  they  differ  from  earth-bound  capabilities.  So,  the  other  major  enhancement  to  the 
CREW  CHIEF  rr  was  the  development  of  a  model  for  performing  maintenance  in  space. 
The  unique  conditions  and  requirements  of  micro-gravity  and  working  in  a  vacuum  dictate  a 
whole  new  set  of  capabilities  and  limitations  for  a  human  model.  Just  as  human  physical 
capabilities  change,  so  too  the  personal  protective  equipment  worn  by  maintainers,  the  actual 
maintenance  tasks  required,  and  even  the  tools  required  by  and  available  to  the  space-bound 
maintainer  are  different. 

According  to  the  CREW  CHIEF  users,  one  of  the  most  desirable  characteristics  of  the 
model  is  the  fact  that  it  interacts  directly  with  the  user's  CAD  drawing,  and  completely  avoids 
any  need  to  translate  the  drawing  from  one  format  into  another.  Indeed,  changes  in  the  design 
of  a  major  weapons  system  are  more  the  rule  than  the  exception,  and  fifty  or  more  changes  in 
a  single  subsystem  each  week  are  not  at  all  unusual.  Under  these  conditions,  designers  do  not 
have  time  to  reformat  their  electronic  drawings.  Consequently,  the  CREW  CHIEF-CAD 
interfaces  were  evaluated  under  this  effort,  with  the  intention  of  ensuring  that  the  aircraft 
designers'  CAD  systems  be  directly  supported  by  the  model.  While  the  original  SOW  required 
rehosting  CREW  CHIEF  to  three  IBM-  and  three  VAX-based  CAD  systems,  the  aerospace 
community  does  not  appear  to  use  many  VAX-based  CAD  systems,  so  only  one  such 
interface  was  developed.  In  addition,  there  were  additional  interfaces  developed  that  do  not 
fall  into  either  of  the  categories  mentioned  above. 
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1.3  Enhance  and  Update  COMBIMAN 


COMBIMAN  development  began  in  the  mid-1970s,  and  includes  many  data  models, 
as  well  as  many  analytical  models.  This  is  a  relatively  mature  product,  but  there  are  still 
enhancements  that  could  improve  the  model  significantly.  The  contract  describes  in  detail  two 
major  enhancements  to  be  performed  on  the  COMBIMAN  model.  In  addition,  since 
COMBIMAN  interacts  directly  with  commercial  CAD  systems  and  databases,  customers  were 
queried  concerning  their  current  and  projected  CAD  development  platforms,  with  the 
intention  of  porting  the  COMBIMAN  model  to  those  particular  platforms. 

When  COMBIMAN  was  first  developed,  3-D  commercial  CAD  systems  did  not  yet 
exist.  Consequently,  since  COMBIMAN  requires  3-D  digitized  data,  it  was  developed  as  a 
stand-alone  CAD  system.  As  mentioned  earlier,  though,  systems  designs  today  change  so 
rapidly  that  designers  do  not  have  the  time  required  to  reformat  these  design  data  just  to 
perform  CAE  analysis.  Therefore,  one  of  the  major  enhancements  required  under  this 
contract  was  to  develop  a  host-independent  COMBIMAN,  using  the  host-independent  CREW 
CHIEF  model  as  a  basis  for  development. 

The  COMBIMAN  model  was  first  developed  assuming  a  specific  seatpan  and  seatback 
angle.  However,  many  of  today’s  high-performance  aircraft  use  reclined  seats.  Modifying 
COMBIMAN  to  accurately  simulate  these  reclined  seats  was  possible,  but  the  procedure  was 
tedious,  and  required  the  COMBIMAN  user  to  modify  both  his  geometry,  as  well  as  the 
sitting  posture  used  for  analysis.  Because  of  this,  the  second  major  enhancement  spelled  out 
in  the  contract  was  to  develop  seat  models  and  a  conform-to-seat  capability  for  COMBIMAN. 

Similar  to  CREW  CHIEF,  COMBIMAN  interacts  directly  with  the  user's  CAD 
drawing,  so  it  needs  to  be  hosted  to  those  CAD  systems  used  by  cockpit  designers.  This 
contract  required  that  these  CAD  systems  be  identified,  and  that  COMBIMAN  be  hosted  to 
them. 
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1.4  General  Support  for  Software  Development 


Besides  all  the  direct  development  work  already  mentioned,  there  are  many  activities 
required  for  supporting  the  models  in  general.  These  activities  cover  a  wide  range  of  topics, 
including  distribution,  training,  configuration  management,  documentation,  validation,  and 
software  and  hardware  acquisition  and  maintenance.  Minor  enhancements,  those  requiring 
significantly  less  effort  than  those  mentioned  earlier,  are  also  covered  under  this  heading. 

The  contract  SOW  required  that  two  video  tapes  be  produced.  The  first  video  tape, 
which  was  to  be  approximately  10  minutes  long,  was  to  display  an  overview  of  CREW 
CHIEF  and  its  capabilities.  The  second  video  tape  was  to  be  instructional,  and  was  to  last 
approximately  30  minutes.  Because  the  contract  was  under-funded,  however,  the  effort  on 
the  first  video  tape  had  to  be  reduced,  and  the  second  tape  had  to  be  eliminated  altogether. 

Many  potential  users  visit  the  Computer-Aided  Workplace  Design  Facility  (CWDEF) 
throughout  the  year,  to  evaluate  the  utility  of  CREW  CHIEF  and  COMBIMAN  for  their 
needs.  Consequently,  demonstrations  of  each  program  must  be  available  at  all  times.  To 
make  the  most  efficient  use  of  these  visitors'  times,  these  demonstrations  must  be  prepared 
and  rehearsed  before  hand. 

Sometimes  users  will  visit  the  CWDEF  to  obtain  training  in  the  use  of  one  or  both 
programs.  These  users  are  often  times  not  well  versed  in  the  use  of  the  CAD  system,  itself. 
Thus  UDRI  developed  and  maintained  training  procedure  and  used  these  procedures  to  teach 
customers  how  to  use  correctly  COMBIMAN  and  CREW  CHIEF. 

Under  the  subject  SOW,  UDRI  was  required  to  use  COMBIMAN  and  CREW  CHIEF 
to  provide  solutions  for  applied  design  problems,  and  to  perform  statistical  analysis  as 
necessary  for  these  design  problems.  Problems  in  several  workplace  designs  were  analyzed 
and  improved  under  this  contract. 

In  order  to  help  disseminate  the  models  and  information  developed  under  this  effort, 
UDRI  intended  to  develop  and  conduct  an  off-site  workshop  on  human  modeling  technology. 
However,  limitations  in  funding  also  prevented  the  successful  development  of  this  workshop. 

Periodic  communication  with  current  users  of  both  COMBIMAN  and  CREW  CHIEF 
are  critical  for  maintaining  tools  that  are  both  useful  and  easy  to  use.  UDRI  conversed  with 
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several  users  to  elicit  both  future  enhancements  and  information  of  problems  encountered 
while  using  these  programs.  This  information  was  used  to  improve  the  models  when  possible. 

Because  of  the  size  and  complexity  of  the  CREW  CHIEF  and  COMBIMAN  models, 
strict  procedures  must  be  followed  to  ensure  that  enhancements  merge  as  seamlessly  as 
possible  with  existing  code  and  functionality.  In  addition,  since  any  corrections  required  in  the 
program  core  modules  must  be  distributed  across  several  hardware  and  CAD  platforms,  strict 
procedures  must  be  in  place  to  ensure  the  corrections  get  added  everywhere.  UDRI  employed 
a  waterfall  software  development  method  to  ensure  these  goals. 

Each  hosting  of  the  human  modeling  programs  must  be  configured  to  allow  it  to  be 
ported  to  systems  outside  the  Air  Force.  It  must  be  configured  to  allow  easy  installation, 
while  not  violating  CAD  vendor  copyrights.  It  must  be  configured  to  allow  easy  installation 
of  updates.  And  it  must  be  configured  to  support  more  than  one  version  of  a  particular  CAD 
host.  UDRI  configured  each  hosting  for  distribution  using  these  criteria. 

Because  of  the  complexity  of  these  programs,  one  must  develop  user's  guides  that 
provide  both  quick  reference  for  procedural  questions,  as  well  as  detailed  reference  for  proper 
application  of  the  software.  These  user's  guides  must  be  tailored  for  each  CAD  host,  since  the 
software  is  tailored  thusly.  Under  previous  contracts,  UDRI  developed  a  format  for  user's 
guides  that  met  these  goals  to  a  large  extent.  The  effort  under  the  current  both  applied  this 
format  to  individual  CAD  hostings,  and  provided  improvement  to  the  format,  as  a  whole. 

In  addition  to  user  documentation,  UDRI  was  required  to  document  the  source  code 
for  both  models,  so  that  future  enhancements  to  the  software  can  be  done  expeditiously.  As  a 
matter  of  course,  UDRI  incorporates  this  type  of  documentation  into  any  source  code  we 
develop.  Because  of  this,  and  because  of  funding  shortfalls,  this  documentation  was  not  set 
down  onto  paper,  and  the  deliverable  items  were  deleted. 

One  of  the  most  important  tasks  required  under  this  contract  is  the  validation  of  all 
software  and  models.  Validation  of  the  CREW  CHIEF  and  COMBIMAN  models  included 
validation  of  the  models,  themselves,  as  well  as  validation  of  the  software.  For  the  models 
both  experimental  and  real-life  tasks  were  used.  The  software  was  generally  validated  using 
100%  testing  on  the  databases. 
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1.5  Ergonomics  Research 


The  amount  of  data  required  to  support  the  CREW  CHIEF  and  COMBIMAN  models 
is  immense.  Some  of  the  data  exist  already,  and  are  maintained  in  an  ergonomics  library 
located  on-base.  Much  of  the  data  need  to  be  collected;  these  experiments  must  be  carefully 
planned  to  ensure  that  enough  and  correct  data  are  collected.  Much  of  this  experimentation 
requires  custom  or  new  laboratory  equipment. 

Whenever  possible,  UDRI  used  existing  data  for  the  COMBIMAN  and  CREW  CHIEF 
models.  However,  the  requirements  of  these  models  are  often  so  stringent  that  data  either  do 
not  exist,  or  are  entirely  inadequate  for  their  needs.  In  these  cases,  UDRI  designed, 
performed,  and  reported  experimentation  to  fulfill  these  data  needs.  Experimentation  was 
performed  measuring  human  physical  and  visual  characteristics  as  they  relate  to  workplace 
accommodation.  In  addition,  a  large  portion  of  the  ergonomic  research  performed  during  this 
contract  was  to  satisfy  data  requirements  for  the  Task  Time  Estimator. 

UDRI  also  provided  support  to  the  Air  Force  by  using  the  COMBIMAN  and  CREW 
CHIEF  programs  to  solve  applied  design  problems.  UDRI  personnel  created  electronic 
mockups  of  the  designs  being  evaluated,  by  either  translating  and  simplifying  existing 
electronic  mockups,  or  by  creating  these  mockups  from  scratch  using  paper-based  technical 
drawings.  The  programs  were  then  exercised  to  evaluate  the  human-workplace  interaction. 

During  the  course  of  this  contract,  UDRI  developed,  acquired,  and  maintained 
equipment  for  the  Physical  Ergonomics  Laboratory.  Most  of  the  fabrication  was  performed  in 
the  workshop  facilities  available  to  the  Physical  Ergonomics  Laboratory.  High-precision 
equipment  was  calibrated  at  the  USAF  PMEL  facility.  Records  for  all  new  and  existing 
equipment  were  maintained. 

UDRI  maintained  and  improved  the  library  facilities  during  this  contract.  Several  new 
items  were  acquired  for  it.  And  a  new  organizational  structure  was  developed  for  it. 

The  work  performed  under  this  contract  was  planned  using  an  integrated  research 
plan.  This  plan  covered  all  aspects  of  the  effort,  including  CAD  system  interfaces,  program 
enhancements,  major  mathematical  models,  and  major  research  thrusts.  In  addition,  each 
individual  research  study  was  fully  planned  and  approved. 


7 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


SECTION  2  -  ENHANCE  AND  UPDA  TE  OF  CREW  CHIEF 


The  contract  SOW  contained  three  major  areas  of  enhancement  for  the  CREW  CHIEF 
model.  The  first  was  the  development  of  a  task  time  estimation  capability  for  aircraft 
maintenance  tasks.  The  second  was  the  development  of  models  of  maintenance  in  space.  And 
the  third  area  was  the  rehosting  of  CREW  CHIEF  on  additional  IBM-  and  Vax -based  CAD 
systems.  In  addition,  all  of  the  CREW  CHIEF  software  and  documentation  had  to  be 
maintained. 


2.1  Develop  Time-to-Repair  Computation 

UDRI's  continued  development  of  the  Task  Time  Estimator  computations  included  the 
following: 

1 .  Study  methods  for  task  time  prediction. 

2.  Study  Industry  Requirements. 

3.  Revise  development  plan. 

4.  Perform  research. 

5.  Develop  TTE  capabilities  for  CREW  CHIEF 

6.  Validate  Time-to-Repair  estimates. 

7.  Hosts  for  enhancements 

Study  Methods  for  Task  Time  Prediction.  During  the  initiation  of  the  Task  Time 
Estimator  UDRI  studied  numerous  methods  of  collecting  and  predicting  task  time  data.  The 
most  commonly  used  methods  are: 

1 .  Occurrence  Sampling  -  used  to  measure  activities  and  delays  of  workers  or 
machines, 

2.  Time  Study  -  used  to  determine  a  time  standard  for  performing  a  given  task,  and 

3.  Predetermined  Time  Systems  -  used  to  predict  task  time  by  assigning 
predetermined  times  to  basic  motions. 

Study  Industry  Requirements.  As  part  of  our  background  research,  UDRI 
contacted  several  major  aircraft  manufacturers  to  gain  a  better  perspective  on  the  current 
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methods  of  predicting  aircraft  maintenance  times.  UDRI  spoke  with  representatives  of  the 
aircraft  companies'  Maintainability  Divisions  to  ascertain  the  current  methods  of  predicting 
aircraft  maintenance  times,  to  present  the  current  capabilities  of  CREW  CHIEF,  and  to 
determine  the  desired  capabilities  of  the  Task  Time  Estimator.  The  five  aircraft  manufacturers 
visited  to  define  requirements  for  the  task  time  estimator  were:  Boeing  Commercial  Aircraft 
Co.,  Seattle,  WA;  Douglas  Aircraft  Co.,  Long  Beach,  CA;  General  Dynamics,  Fort  Worth, 
TX;  Lockheed  Aeronautical  Systems  Corp.,  Burbank,  CA;  and  Rockwell  International, 
Lakewood,  CA. 

Revise  Development  Plan.  Throughout  the  development  of  the  Task  Time 
Estimator,  UDRI  continued  to  revise  and  update  the  TTE  development  plan  as  a  result  of 
experimentation  and  discussions  with  the  Air  Force,  and  our  sub-contractors  at  Anthropology 
Research  Project,  and  Texas  Tech  University.  Development  plans  and  revisions  were 
presented  to  the  Air  Force  during  a  Preliminary  Design  Review  (PDR)  {Attch  1,  CDRL 
Sequence  3),  a  Critical  Design  Review  (CDR)  {Attch  1,  CDRL  Sequence  3},  and  the  final 
Research  Program  Plan,  Volume  I  (Attch  1,  CDRL  Sequence  5}. 

Perform  Research.  UDRI  planned  and  conducted  numerous  time  and  motion  studies 
during  this  contract  employing  nearly  500  subjects  logging  over  1100  hours  of  actual  data 
collection. 

Develop  TTE  Capabilities  for  CREW  CHIEF.  The  Task  Time  Estimation  (TTE) 
function  calculates  the  time  required  to  remove  and  replace  individual  components  and 
subsystems  within  a  proposed  design.  This  function  takes  into  account  such  things  as 
obstruction  cased  by  other  parts  of  the  system,  body  posture,  clothing,  fatigue,  and  also  the 
tools  being  used  (if  any). 

Validate  Time-to-Repair  Estimates.  UDRI  performed  time  study  research  to 
validate  existing  data  and  developed  a  plan  for  validating  the  Task  Time  Estimator  time-to- 
repair  estimates. 

2.1.1  Study  Methods  for  Task  Time  Prediction 

During  the  initiation  of  the  Task  Time  Estimator  UDRI  studied  numerous  methods  of 
collecting  and  predicting  task  time  data.  The  most  commonly  used  methods  are: 
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1 .  Occurrence  Sampling  -  used  to  measure  activities  and  delays  of  workers  or 
machines, 

2.  Time  Study  -  used  to  determine  a  time  standard  for  performing  a  given  task,  and 

3.  Predetermined  Time  Systems  -  used  to  predict  task  time  by  assigning 
predetermined  times  to  basic  motions. 

The  following  is  a  brief  description  of  those  three  methods. 

Occurrence  Sampling  is  exactly  what  its  name  implies.  Sample  observations  are 
made  at  random  over  a  period  of  time  to  detect  the  occurrence  of  the  activity  under  study. 
Occurrence  Sampling  has  three  main  uses:  (1)  to  determine  the  percentage  of  the  day  that  a 
person  is  working  and  the  percentage  that  he  or  she  is  not  working,  (2)  to  establish  a 
performance  index  or  performance  level  for  a  person  during  his  or  her  working  time,  and  (3) 
to  establish  a  time  standard  under  certain  circumstances.  Establishing  a  time  standard  using 
Occurrence  Sampling  is  done  by  simply  dividing  the  number  of  work  units  produced  by  the 
time  the  person  was  performing  work.  For  example,  it  is  determined  over  the  course  of  a 
two-week-long  Occurrence  Sampling  study  that  a  person  is  working  85%  of  the  time,  and  that 
he  or  she  produce  )  work  units  during  that  time;  the  time  for  a  single  unit  would  be: 

80  hours  x  .85  =  68  hours 
100  units/68  hours  =  1.47  units/hour 

Although  Occurrence  Sampling  can  be  used  in  some  cases  to  determine  time 
standards,  it  is  generally  agreed  that  time  study  and  the  use  of  Predetermined  Time  Systems 
(PTSs)  are  superior  for  that  purpose.  Therefore,  occurrence  sampling  was  not  used  as  a  data 
collection  method. 

Time  study  is  a  technique  of  establishing  an  allowed  time  for  performing  a  given  task 
based  upon  measurement  of  the  work  content  of  the  prescribed  method.  The  objective  of  time 
study  is  to  determine  reliable  time  standards  for  all  work  both  direct  and  indirect.  (Indirect 
work  involves  such  things  as  machine  time  which  is  beyond  the  control  of  the  worker.)  The 
exact  procedure  for  performing  a  time  study  may  vary  depending  upon  the  type  of  operation 
being  studied.  However,  there  are  four  fundamental  steps: 
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Step  1 :  Define  task  method 


The  first  step  is  to  accurately  define  the  task  and  the  exact  method  for  performing  the 
task.  This  is  done  by  partitioning  the  task  into  task  elements  and  recording  the  complete 
description  of  each  element  and  the  sequence  in  which  the  elements  are  performed. 

Step  2:  Measure  task  time 


Once  the  task  method  has  been  defined  and  divided  into  elements,  the  next  step  in 
performing  a  time  study  is  to  actually  measure  the  time  required  to  perform  each  element  of 
the  task. 

Step  3:  Rate  the  operator's  performance 

The  next  step  in  conducting  a  time  study  is  to  rate  the  operator's  (or  technician's) 
performance.  The  pace,  or  rate  of  speed  at  which  the  operator  performs  a  task,  directly 
influences  the  measured  time. 

Step  4:  Determine  the  number  of  samples  to  measure 

The  time  required  to  perform  the  elements  of  an  operation  may  vary  slightly  from  one 
time  to  the  next.  Variations  in  time  may  result  from  such  things  as  a  difference  in  the  exact 
position  of  the  parts  and  tools  used  by  the  operator,  or  from  possible  differences  in 
determining  the  exact  end  points  by  the  analysts.  Time  study  is  a  sampling  process;  thus  the 
greater  the  number  of  task  cycles  timed,  the  more  closely  the  results  will  represent  the  activity 
being  measured. 

The  formula  show  below  can  be  used  to  estimate  the  number  of  samples  needed  to  estimate 
the  true  average  time  values. 

Let  N  =  actual  number  of  readings  of  an  element, 
and 


X  =  individual  readings  of  an  element. 
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Then 


-  zx 

X= -  =  average  of  sample  mean  of  all  readings  of  that  element. 

N 

Now  N'  represents  the  required  number  of  observations  to  predict  the  true  time  within  +5% 
precision  and  95%  confidence  level  (i.e.,  the  chances  are  at  least  95  out  of  100  that  the  sample 
mean  will  be  in  error  more  than  +5%  of  the  true  element  time)  is  given  by: 

-{  TX  J 

If  a  90%  confidence  level  and  a  precision  of  ±10%  are  used  as  the  criteria,  then  the  formula  will 
be: 


N'  = 


±0±v£.jf!-(£x) 


A 


J 
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The  first  Predetermined  Time  System  (PTS)  was  developed  to  establish  motion  time 
values.  In  the  original  research,  the  operations  were  filmed  and  then  analyzed  frame-by-frame. 
The  researchers  defined  the  basic  motions,  such  as  reach  and  move.  The  time  values  for  these 
motions  could  then  be  determined  by  counting  the  number  of  elapsed  frames  of  film. 

The  procedure  for  determining  standard  times  using  a  PTS  is  relatively 
straightforward,  but  requires  a  high  degree  of  precision  and  skill  by  the  analyst  to  produce 
accurate  and  consistent  results.  To  compute  a  total  time  for  a  task,  the  task  must  first  be 
divided  into  the  specific  motions  recognized  by  the  particular  PTS.  Predetermined  Time 
Systems  have  divided  motions  into  classes  of  motions  such  as  reach,  grasp,  select,  position, 
search,  etc.  Each  class  of  motions  is  further  subdivided  into  specific  categories.  For  example, 
a  reach  can  be  divided  by  the  different  lengths  of  reach  (i.e.,  1,  2,  3,  ...  30  in.),  and  types  of 
reach  (i.e.,  reach  to  object  in  fixed  location,  reach  to  object  whose  general  location  is  known, 
reach  to  object  jumbled  in  a  group  with  other  objects,  reach  to  a  small  object,  etc.).  Once  the 
task  has  been  divided  into  its  basic  motions,  the  times  for  each  motion  are  obtained  from  the 
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PTS  database.  To  determine  the  normal  time  estimate,  the  time  values  associated  with  each 
motion  of  the  task  are  summed. 

Predetermined  Time  Systems  can  be  defined  as  functional,  specific,  or  generic.  A 
functional  system  is  one  that  has  been  adapted  for  use  in  a  particular  type  of  work  (i.e., 
clerical).  A  specific  PTS  is  one  that  has  been  developed  for  a  particular  industry  or 
organization.  Generic  systems  are  systems  that  can  be  used  in  a  variety  of  different  activities. 
The  defined  motions  of  a  generic  system  can  be  used  to  describe  almost  any  type  of  task. 

Predetermined  Time  Systems  also  differ  in  the  complexity  of  their  basic  elements.  A 
basic-level  system  is  a  system  whose  elements  consist  mostly  of  single  motions  that  cannot  be 
further  subdivided.  Second-level  systems  combine  two  or  more  of  the  single  elements  of  a 
basic  system  into  a  multi-motion  element.  Third-  and  fourth-level  systems  combine  even  more 
elements  of  a  basic  system  to  form  their  basic  elements.  As  the  system  level  increases  the 
work  content  of  each  element  increases. 

In  our  study  of  existing  methods  of  predicting  aircraft  maintenance  task  time,  IJDRI 
investigated  over  25  Predetermined  Time  Systems.  Two  of  those  systems  included  Boeing's 
Airplane  Maintenance  Engineered  Time  Standards  (AMETS)  and  a  system  developed  by  the 
Navy  called  Elemental  Standard  Data  System  (ESD).  Both  of  these  systems  were  developed 
specifically  for  use  with  aircraft  maintenance.  Boeing's  AMETS  system  is  a  direct  application 
of  the  Navy  system.  The  Navy's  ESD  system  is  a  multi-level  system  composed  of  Methods- 
Time  Measurement  (MTM)  and  the  Naval  Aviation  Logistics  Center  (NALC)-developed  data. 

Methods-Time-Measurement.  Methods-Time-Measurement  (MTM)  is  the  most 
widely  used  Predetermined  Time  System.  The  MTM  system  is  a  basic  level,  generic  PTS 
originally  developed  from  the  study  of  industrial  operation  and  first  published  in  1948.  MTM 
consists  of  12  categories  of  basic  motions:  reach;  move;  turn;  apply  pressure;  grasp;  position; 
release;  disengage;  eye  travel  and  eye  focus;  body,  leg,  and  foot  motions;  secondary  engage; 
and  crank.  Analysis  of  a  task  using  MTM  involves  breaking  down  the  task  into  the  systems 
basics  motions,  determining  the  nature  of  the  motions  and  the  conditions  under  which  the 
motions  are  performed.  Additionally,  some  basic  motions  can  be  performed  simultaneously 
and  some  cannot.  Once  the  motion  patterns  have  been  determined,  time  values  can  be 
assigned  to  each  motion  and  summed  for  a  total  task  time. 
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MTM-General  Purpose  Data.  MTM-General  Purpose  Data  (MTM-GPD)  was 
developed  to  simplify  the  application  of  MTM  by  providing  single  element  time  values  for 
commonly  used  MTM  motion  patterns,  thereby  eliminating  repeated  motion-by-motion 
analysis.  MTM-GPD  elements  are  described  in  non-specific  terms  to  permit  the  widest 
possible  application.  The  MTM-GPD  data  elements  were  derived  from  MTM  analysis  of 
repetitive  motion  patterns  submitted  by  members  of  the  MTM  Association  for  Standards  and 
Research,  and  were  officially  adopted  by  the  Association  in  1963.  The  principle  use  of  MTM- 
GPD  is  as  a  first  level  building  block  in  the  development  of  more  comprehensive  standard  data 
such  as  the  Navy's  Elemental  Standard  Data.  MTM-GPD  is  also  commonly  used  directly  as  a 
substitute  for  detailed  MTM  analysis. 

Elemental  Standard  Data.  ESD  is  a  Predetermined  Time  System  based  on  MTM- 
GPD  and  is  composed  of  two  types  of  data.  Universal  and  Specific.  Universal  data  are 
composed  of  three  levels  of  data:  basic-purpose,  multi-purpose,  and  omni-purpose.  Basic  and 
multi-purpose  data  are  composed  of  MTM-GPD  and  supplemented  with  NALC  developed 
multi-purpose  data.  The  third  data  level  is  omni-purpose  data  which  consist  of  908  coded 
data  elements,  each  describing  the  complete  accomplishment  of  an  element  of  work.  Omni¬ 
purpose  data  are  composed  of  MTM-GPD  basic  and  multi-purpose  data  and/or  other  Omni¬ 
purpose  data  elements.  Each  Omni-purpose  data  element  has  a  time  value  for  installation, 
removal,  or  others  as  may  apply.  Omni-purpose  elements  also  include  times  for  first  piece  or 
additional  piece,  if  appropriate.  The  first  piece  is  defined  as  those  motions  necessary  to 
accomplish  the  element,  as  defined  in  its  work  content,  separate  and  apart  from  any  other 
element.  The  additional  piece  is  defined  as  only  those  motions  necessary  to  accomplish  the 
"do"  portion  of  the  element. 

The  ESD  Omni-data  contain  times  for  the  use  of  most  common  aircraft  tools  and 
fasteners.  ESD  omni-purpose  data  elements  represent  an  average  of  acceptable  shop 
maintenance.  During  the  development  of  the  data,  each  element  was  analyzed  to  incorporate 
the  practical  expectations  associated  with  low  volume  repair  and  maintenance  tasks.  Each 
omni-purpose  data  element  represents  an  average  time  value  for  two  or  more  MTM-GPD 
analysis  of  similar  units  of  work.  For  example,  the  element  time  for  removing  a  bolt  with  a 
wrench  is  computed  from  the  average  of  three  MTM-GPD  analyses  of  removing  a  bolt  using 
different  types  of  wrenched.  This  method  of  using  an  average  time  for  like  tasks  is  similar  to 
the  method  of  bench  marking  task  times  used  in  some  time-slotting  techniques  (a  comparative 
estimation  approach  of  developing  maintenance  time  standards). 
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The  ESD  system  also  includes  a  procedure  for  accounting  for  the  difficulty  of  an  omni¬ 
purpose  data  element.  ESD  defines  five  levels  of  difficulty  ranging  from  1)  very  easy,  to  5) 
very  difficult.  Difficulty  is  defined  in  terms  of  three  variables  which  effect  the  time  to 
accomplishing  a  data  element,  weight,  distance,  and  control.  Each  of  these  variables  are 
weighted  to  represent  their  relative  impact  on  time,  with  control  accounting  for  85%  of  total 
difficulty,  for  the  majority  of  omni-purpose  data  elements. 

Although  much  of  the  data  in  the  ESD  system  were  developed  for  shop  work,  many 
elements  describe  maintenance  tasks  that  are  performed  on  the  flight  line  and  are  well-suited 
for  use  in  the  Task  Time  Estimator  (TTE),  such  as  the  installation  and  removal  fasteners. 
Therefore,  UDRI  decided  to  use  ESD  omni-purpose  data  as  a  starting  point  for  building  the 
TTE.  Furthermore,  the  MTM-GPD  data  upon  which  the  omni  elements  were  constructed,  are 
available  and  will  allow  the  modification  of  the  elements. 

Upon  receiving  the  ESD  data  from  the  Navy,  UDRI  decomposed  each  of  the  Omni¬ 
level  elements  into  the  MTM-GPD  elements  from  which  they  were  constructed.  We  found 
numerous  errors  through  out  the  database.  Errors  included  such  things  as  incorrect 
multiplication  factors,  and  errors  in  summation.  Most  of  the  errors  found  in  the  data  were 
clerical  in  nature  and  could  be  attributed  to  the  fact  that  the  ESD  d  e  was  created  from 
manual  calculation  and  subsequently  entered  manually.  Much  of  the  data  entry  was  done  by 
inmates  in  the  State  of  California,  and  some  of  the  data  were  never  entered  into  a 
computerized  database  at  all.  UDRI  entered  that  portion  of  the  data  which  had  not  previously 
been  entered,  then  re-computed  and  recompiled  the  entire  ESD  Omni  database.  We  also 
composed  a  list  of  all  the  errors  that  we  found  and  corrected,  and  sent  it  to  the  Navy. 

Data  Collection  Procedures.  UDRI  performed  two  pilot  time  study  experiments  for 
the  purpose  of  testing  our  procedures  for  conducting  time  studies.  The  first  pilot  study  was 
designed  to  investigate  the  effects  of  arm  and  hand  clearance  on  the  time  required  to  perform 
a  simple  installation  task.  The  task  involved  positioning  a  small,  flat,  round  object 
(approximately  4  inches  in  diameter)  onto  a  medal  mounting  plate  and  securing  it  with  four 
1/4  inch  bolts,  using  a  boxed  end  wrench.  The  object  was  positioned  transverse  to  the  subject 
with  the  bolts  installed  from  the  subjects  right.  A  vertical  barrier  was  placed  to  the  right  of  the 
object  to  provide  interference  with  the  arms  and  hands,  but  not  with  the  tool.  Five  levels  of 
interference  were  used  between  the  barrier  and  the  mounting  plate:  9,  6,  4,  3,  and  2  inches. 
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The  subjects  were  two  male  UDRI  employees  who  volunteered  to  participate.  The 
first  subject  performed  the  installation  task  10  times  for  each  of  the  five  barrier  placements. 
After  the  first  subject  completed  the  ten  trials  at  the  6  inch  barrier  placement,  it  was  decided 
that  barrier  placement  did  not  cause  an  increased  interference  and  was  omitted  for  the  second 
subject. 


Although  the  study  only  employed  two  subjects,  it  provided  two  major  findings.  The 
first  involved  the  effects  of  practice.  The  first  subject  tested  was  very  well  practiced  on  the 
task  before  the  study  began,  having  performed  the  task  approximately  50  times.  The  second 
subject  was  given  only  five  trials  practice  before  the  study  began.  Once  the  study  began, 
performance  of  the  second  subject  improved  gradually  over  the  first  20  trials,  while 
performance  of  the  first  subject  remained  relatively  constant. 

Since  the  proficiency  at  which  the  subject  performs  has  a  direct  effect  on  the  time,  it 
was  concluded  that  subjects  should  be  well  practiced  before  testing  begins  in  future  studies  in 
order  to  accurately  determine  the  effects  of  the  variables  under  study.  (Further  studies  found 
this  assumption  to  be  incorrect.  But  more  about  that  later.) 

The  second  major  finding  in  this  study  was  the  ability  of  subjects  to  adapt  to  the 
situation.  It  was  expected  that  decreasing  the  distance  between  the  barrier  and  the  object 
would  increase  the  installation  time  due  to  restricted  arm  and  hand  clearance.  However,  the 
barrier  had  no  effect  at  the  9,  6,  4,  and  3  inch  levels.  At  those  levels,  the  subjects  were  able  to 
adjust  by  using  more  hand  and  finger  motion,  so  restrictions  on  arm  movements  caused  no 
increase  in  time.  Only  the  2  inch  level  showed  an  increase  in  time.  At  the  2  inch  level,  hand 
and  finger  movements  were  also  restricted. 

The  next  pilot  study  involved  a  one  handed  installation  task  working  through  an  access 
opening.  The  object  installed  was  placed  on  a  flat  horizontal  surface  and  secured  with  four 
1/4  inch  bolts  using  a  boxed  end  wrench.  The  variables  investigated  in  this  study  were  access 
opening  size,  visibility,  object  location,  and  reach  interference.  Two  access  opening  sizes 
were  used,  5"  x  5"  and  9"  x  9".  The  fixture  used  to  provide  the  access  opening  was  a  wooden 
frame  which  did  not  obstruct  visibility.  Three  objects  were  used,  a  4  x  4  inch  flat  metal  plate, 
a  4  x  4  inch  flat  metal  plate  with  a  3  x  3  x  3  inch  solid  wooden  cube  mounted  in  the  center, 
and  a  4  x  4  inch  flat  metal  plate  with  a  3  x  3  x  3  inch  transparent  Plexiglas  cube  mounted  in 
the  center.  Each  of  the  plates  had  four  mounting  holes,  one  on  each  side  of  the  square  plate. 
The  holes  were  located  2  inches  from  the  top  and  bottom  of  the  plate  and  1/2  inch  from  the 
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side.  The  flat  plate  was  used  as  a  control  condition.  The  plate  with  the  wooden  cube  in  the 
center  caused  the  subject  to  reach  around  the  cube  in  order  to  install  two  of  the  four  bolts. 

The  wooden  cube  also  completely  obscured  vision  to  those  two  bolts.  The  plate  with  the 
Plexiglas  cube  also  required  the  subject  to  reach  around  the  cube  to  install  two  of  the  bolts, 
yet  did  not  obscure  the  subjects  vision  of  those  bolts. 

Each  object  was  installed  at  three  different  locations  relative  to  the  access  opening, 
centered  directly  in  front  of  the  opening,  and  12  inches  to  the  left  and  right  of  the  center  of  the 
opening.  When  the  object  was  located  to  the  right  of  the  opening,  installation  was  performed 
with  the  left  hand.  All  other  installation  tasks  were  performed  with  the  right  hand. 

The  first  two  subjects  in  this  study  were  UDRI  employees,  who  were  also  the  study 
experimenters.  From  the  results  of  the  first  pilot  study,  it  was  decided  that  the  installation 
task  be  very  well  practiced.  So,  each  subject/experimenter  performed  each  of  the  task 
conditions  repeatedly  until  their  installation  time  ceased  to  decrease  with  subsequent  trials. 
Analysis  of  their  data  showed  an  astounding  absence  of  any  effect  between  any  of  the 
conditions  tested.  Through  repetition,  these  subjects  had  become  so  efficient  at  performing 
the  task  that  restricted  visual  and  physical  accessibility  caused  by  the  apparatus  was  no  longer 
a  hindrance. 

From  the  results  of  the  previous  study,  it  was  felt  that  a  maximum  level  of  proficiency 
was  needed  in  order  to  prevent  the  effects  of  practice  from  masking  the  effects  of  the  variables 
being  studied.  However,  the  results  of  this  study  showed  that  maximum  proficiency  can  also 
mask  the  variables  effects.  Therefore,  it  was  decided  that  a  better  method  of  controlling  the 
effects  of  practice  would  be  through  experimental  design. 

The  study  was  repeated  using  two  UDRI  technicians  as  subjects.  These  subjects  were 
given  limited  practice  to  allow  them  to  become  familiar  with  the  task,  yet  not  enough  to  gain 
any  significant  level  of  proficiency.  Once  testing  began,  each  subject  performed  each  of  the 
installation  tasks  in  random  order.  Each  task  was  performed  four  times  in  two  test  sessions, 
two  per  session. 

Since  only  two  subjects  were  used,  the  randomization  procedure  did  not  actually 
control  the  effects  of  practice.  However,  the  limitation  on  the  number  of  repetitions  did 
produce  the  expected  effects  of  the  variables  studied.  The  major  finding  in  this  study  was  not 
the  effects  of  the  variables,  but  rather  the  discovery  of  a  better  method  for  designing  future 
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time  study  experiments.  The  method  of  controlling  the  effects  of  practice  through 
experimental  design  and  procedures,  is  also  more  consistent  with  the  way  maintenance  is 
actually  performed.  Maintenance  technicians  are  familiar  with  the  tasks  they  perform. 
However,  most  maintenance  tasks  are  performed  infrequently  and  maximum  proficiency  is 
never  actually  obtained. 

2.1.2  Study  Industry  Requirements 

As  part  of  our  background  research,  UDRI  contacted  several  major  aircraft 
manufacturers  to  gain  a  better  perspective  on  the  current  methods  of  predicting  aircraft 
maintenance  times.  UDRI  spoke  with  representatives  of  the  aircraft  companies' 

Maintainability  Divisions  to  ascertain  the  current  methods  of  predicting  aircraft  maintenance 
times,  to  present  the  current  capabilities  of  CREW  CHIEF,  and  to  determine  the  desired 
capabilities  of  the  Task  Time  Estimator.  The  five  aircraft  manufacturers  visited  to  define 
requirements  for  the  task  time  estimator  were:  Boeing  Commercial  Aircraft  Co.,  Seattle,  WA; 
Douglas  Aircraft  Co.,  Long  Beach,  CA;  General  Dynamics,  Fort  Worth,  TX;  Lockheed 
Aeronautical  Syr  Corp.,  Burbank,  CA;  and  Rockwell  International,  Lakewood,  CA. 

One  of  the  key  differences  between  the  companies  contacted  was  the  fact  that  Boeing 
Commercial  Aircraft  Company  develops  commercial  aircraft,  whereas  the  other  four 
companies  develop  military  aircraft.  In  developing  military  aircraft,  there  are  many  Military 
Standards  by  which  the  companies  must  abide.  In  the  commercial  industry,  the  companies 
avoid  mandatory  restrictions  in  design  but  are  faced  with  customizing  the  aircraft.  Companies 
which  develop  military  aircraft  focus  on  the  performance  requirements  of  the  aircraft,  while 
commercial  aircraft  companies  focus  on  maintainability  and  turn-around  time.  This  difference 
can  be  seen  in  their  approach  to  estimating  maintenance  time  requirements.  Boeing 
Commercial  Aircraft  Co.  developed  the  Airplane  Maintenance  Engineered  Time  Standards 
(AMETS)  computerized  time  system  for  work  measurement  and  predicting  maintenance  times 
for  new  aircraft.  AMETS  is  a  direct  application  of  the  Navy's  Elemental  Standard  Data  (ESD) 
computerized  for  quick  retrieval  of  task  element  times  and  reporting.  The  four  military 
aircraft  manufacturers  rely  on  comparisons  to  existing  systems,  estimates  from  experienced 
maintainability  engineers,  time  study  from  mock-ups,  prototype  and  production  aircraft,  and 
historical  data  collected  through  AFM  66-1  programs  (AFM  66-1  data  are  reported  as  gross 
time  to  complete  a  task,  with  no  break  down  of  time  to  separate  the  task  elements). 
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In  our  discussions  with  representatives  from  the  five  aircraft  manufacturers  we  found 
that  in  general,  aircraft  designers  expressed  a  desire  for  a  system  which  can  be  used  to 
evaluate  the  degree  of  difficulty  of  maintaining  a  specific  design,  with  the  goal  of  determining 
if  redesign  is  required  to  improve  maintainability,  while  maintainability  engineers  expressed  a 
need  for  a  system  which  would  provide  an  accurate  estimation  of  task  time.  The  following  are 
the  suggestions  made  by  each  of  the  aircraft  companies  contacted. 

Boeing  Commercial  Aircraft  Company  showed  great  interest  in  the  TTE  providing  a 
maintenance  task  time,  and  suggested  that  the  maintenance  tasks  be  coded  by  part  number 
instead  of  by  the  elements  since  the  designers  know  the  part  numbers.  Boeing  also  mentioned 
a  need  for  delay  factors  but  were  unsure  of  whether  it  should  be  incorporated  into  CREW 
CHIEF  or  left  as  a  separate  system. 

General  Dynamics  expressed  an  interest  in  having  the  TTE  predict  the  time  per  event 
of  a  task  and  also  to  provide  a  complexity  factor.  The  maintainability  engineers  at  General 
Dynamics  wanted  task  time  to  take  into  account  the  limited  arc  for  a  wrench  which  causes  "x" 
partial  revolutions  to  secure  a  bolt  with  "y"  threads.  They  also  wanted  a  time  so  that  the 
designers  would  understand  the  need  for  redesign.  The  complexity  factor  would  provide  a 
means  of  adjusting  the  task  times  to  compensate  for  such  things  as  ranges  in  personnel  size, 
personnel  strength,  amount  of  interference,  and  design  complexity.  They  would  like  the 
capability  to  predict  a  mean  and  maximum  corrective  task  time  based  on  the  design 
characteristics  and  the  physical  characteristics  of  the  human  model. 

Douglas  Aircraft  indicated  an  interest  in  a  TTE  program  which  would  provide  both  a 
rating  factor  and  a  maintenance  task  time.  Since  their  aircraft  designers  are  not  concerned 
with  a  maintenance  time,  they  would  require  a  rating  factor  to  help  them  discover  the.  need  for 
redesign  for  ease  of  repair.  The  maintainability  engineers  would  like  a  time  prediction  model 
that  would  provide  them  with  a  real  time  instead  of  the  present  estimated  times. 

Lockheed  expressed  an  interest  in  the  TTE  providing  (1)  discrete  predicted  times  for 
maintenance  and  (2)  correction  factors.  The  engineers  in  the  Structures  Group  would  like  to 
predict  task  times  down  to  the  particular  fastener  used  so  they  can  find  quantifiable  design 
problems  early.  The  maintainability  engineers  would  like  a  combination  of  both  task  time  and 
factors.  They  need  correction  factors  for  the  environment  so  that  they  can  adjust  task  times 
for  other  climates.  They  would  also  like  correction  factors  for  fatigue. 
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Rockwell  International  expressed  an  interest  in  the  TTE  providing  task  times  and 
difficulty  factors.  The  task  times  would  be  used  for  comparative  purposes  by  the 
maintainability  engineers.  The  main  concern  of  the  designers  would  be  the  level  of  difficulty 
of  a  task  based  on  component  design  and  location  in  the  aircraft.  Rockwell  would  like  a  set  of 
delay  factors  which  the  designer  could  generate  from  the  program  for  a  particular  task.  The 
factors  would  tell  the  designer  that  the  current  design  of  a  component  will  cause  an  increase  in 
repair  time  by  3.5  times  the  ideal  time,  for  example,  due  to  the  difficulty  of  the  task. 

2.1.3  Revise  Development  Plan 

Throughout  the  development  of  the  Task  Time  Estimator,  UDRI  continued  to  revise 
and  update  the  TTE  development  plan  as  a  result  of  experimentation  and  discussions  with  the 
Air  Force,  and  our  sub-contractors  at  Anthropology  Research  Project,  and  Texas  Tech 
University.  Development  plans  and  revisions  were  presented  to  the  Air  Force  during  a 
Preliminary  Design  Review  (PDR)  {Attch  1,  CDRL  Sequence  3},  a  Critical  Design  Review 
(CDR)  (Attch  1,  CDRL  Sequence  3),  and  the  final  Research  Program  Plan,  Volume  I  (Attch 
1,  CDRL  Sequence  5). 

Preliminary  Design  Review.  As  a  result  of  discussions  with  the  Air  Force, 
representatives  of  aircraft  manufacturers,  and  our  sub-contractors  at  Anthropology  Research 
Project,  and  Texas  Tech  University,  UDRI  developed  three  strategies  for  the  development  of 
the  Task  Time  Estimator.  These  three  strategies  were  presented  to  the  Air  Force  during  the 
Preliminary  Design  Review.  At  this  point  in  the  TTE  development,  laboratory  methods  for 
collecting  maintenance  task  times  and  the  basic  structure  of  the  TTE  database  had  already 
been  determined.  The  design  problem  which  remained  was  how  to  determine  the  difficulty  of 
aircraft  maintenance  tasks,  and  present  it  to  the  user.  The  three  approaches  for  determining 
task  difficulty  presented  at  the  CDR  were  1)  Difficulty  Factors,  2)  Hierarchical  Elements,  and 
3)  Difficulty  Levels. 

The  Difficulty  Factor  approach  was  considered  as  a  result  of  discussions  with  aircraft 
designers.  They  expressed  a  need  for  a  numeric  value  which  could  be  used  to  represent  the 
relative  difficulty  of  a  task.  With  this  approach  a  difficulty  factor  would  be  the  result  of  a  ratio 
between  the  time  required  to  perform  a  task  under  normal  conditions  and  the  time  required  for 
the  same  task  when  difficult  conditions  are  encountered.  For  example,  if  the  time  required  to 
install  a  bolt  under  normal  conditions  is  X  seconds,  and  the  time  required  when  interference  in 
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encountered  is  Y  seconds,  the  resulting  difficulty  factor  is  X/Y.  The  problem  with  this 
approach  is  that  it  requires  all  the  information  needed  to  determine  the  actual  task  times.  It 
was  decided  that  presenting  the  user  with  the  actual  task  time  for  the  condition  under  which  it 
is  performed  is  more  desirable.  The  user  would  still  have  the  ability  to  compute  a  difficulty 
factor,  although,  it  may  require  the  user  to  perform  multiple  analyses. 

The  Hierarchical  Element  approach  was  developed  through  input  from  our  sub¬ 
contractor  at  Texas  Tech  University.  In  this  approach  all  remove  and  replace  tasks  would  be 
defined  by  eight  elements  at  the  top  of  the  hierarchy.  Each  of  these  elements  would  be 
defined  as  a  combination  of  task-hardware  and  task-method  factors,  each  factor  would  be 
defined  by  variables,  and  each  variable  would  be  defined  by  levels.  The  difficulty  of  each 
element  would  be  evaluated  by  making  a  decision  at  each  step  in  the  Element  -  Factor  (both 
hardware  and  method)  -  Variable  -  Level  hierarchy.  The  bottom  level  of  the  hierarchy  would 
contain  the  task  times.  The  problem  with  this  approach  is  the  amount  of  data  it  would 
require.  In  the  simple  example  presented  at  the  CDR,  data  for  61,803  different  conditions 
would  need  to  be  collected. 

The  Difficulty  Level  Approach  was  developed  from  examination  of  the  method  used 
by  the  Navy  for  determining  task  difficulty  in  the  development  of  their  Elemental  Standard 
Data  (ESD).  In  this  approach  the  difficulty  of  each  task  element  is  determined  by  three 
variables  which  affect  the  difficulty  of  the  task,  weight,  distance,  and  control.  Each  of  these 
variables  are  evaluated  in  terms  of  five  levels  of  difficulty  ranging  from  "very  easy"  to  "very 
difficult."  In  addition,  each  variable  is  weighted  according  to  its  significance  toward  task 
difficulty.  In  the  ESD  system,  data  were  developed  from  MTM-GPD  for  the  first  three  levels 
of  difficulty.  The  two  most  difficulty  levels  were  extrapolated  using  a  time/difficulty  ratio 
equation.  The  ESD  definition  for  each  difficulty  level  for  the  variables  weight  and  distance  are 
discrete  numeric  values.  However,  difficulty  for  control  is  defined  in  subjective  terms  which 
requires  expertise  and  experience  on  the  part  of  the  user.  Furthermore,  the  variable  control  is 
the  most  significant  in  determining  difficulty.  For  most  of  the  ESD  elements  control  accounts 
for  85%  of  task  difficulty.  The  problem  with  this  approach  is  the  lack  of  empirical  data  for  the 
variable  "control." 

Critical  Design  Review.  Through  consultation  with  the  Air  Force,  and  our  sub¬ 
contractors,  UDRI  decided  that  a  method  similar  to  that  used  in  the  ESD  difficulty  level 
approach  for  determining  task  difficulty  was  the  most  feasible.  However,  instead  of  using  five 
discrete  levels  of  difficulty,  a  continuous  scale  would  be  used.  This  decision  was  supported  by 
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data  collected  in  the  Physical  Economics  Lab.  Comparison  of  laboratory  data  with  ESD  data 
was  very  favorable,  supporting  the  validity  of  the  method.  UDRI  presented  the  research 
finding,  and  pri  posed  future  research  for  the  development  of  the  TTE,  to  the  Air  Force  at  the 
Critical  Design  Review. 

The  proposed  research  concentrated  on  three  major  task  categories  most  common  to 
aircraft  maintenance:  plumbing,  avionics  electronic  equipment,  and  mechanical  components. 
The  maintenance  actions  performed  within  each  of  these  categories  contain  the  majority  of 
tasks  required  in  aircraft  maintenance. 

Plumbing.  Aircraft  engine  plumbing  consists  of  tubing  and  fittings  for  fuel,  oil, 
hydraulic  fluid,  and  other  fluids  and  gases.  Maintenance  of  plumbing  requires  specific  tools 
such  as  flare  wrenches.  The  tools  are  used  on  fittings  and  couplings,  whereby  nuts  and  bolts 
are  used  infrequently.  The  objects  handled  are  not  usually  heavy  but  often  must  be  handled 
with  care  to  prevent  kinking  or  denting.  It  will  only  be  necessary  to  test  the  removal  and 
replacement  of  the  plumbing  as  complete  assemblies  because  the  connections  and  fittings  are 
installed  on  the  tubing  in  the  shops. 

Avionics  Equipment.  Avionics  equipment,  commonly  called  black  boxes,  requires 
frequent  removal  and  replacement  for  calibration  and  repair  and,  for  this  reason,  is  commonly 
designed  to  fit  in  easily  accessed  racks  or  compartments  and  is  often  held  in  place  with  captive 
fasteners.  The  components  tend  to  be  symmetrical  and  fairly  easy  to  handle  although  some 
are  quite  heavy.  The  equipment  is  usually  delicate  and  must  be  handled  with  care. 

Mechanical  Components.  Mechanical  components  are  the  largest  area  of  concern. 
They  consist  of  aircraft  items  such  as  hydraulic  and  fuel  pumps,  generators,  actuators,  etc., 
and  hardware  such  as  brackets,  bell  cranks,  and  flight  controls.  Avionics  equipment  such  as 
radomes  and  antennas  also  fall  into  this  category.  Mechanical  components  often  have 
electrical  and  plumbing  connections  and  are  secured  to  the  aircraft  structure  by  nuts  and  bolts. 
They  often  are  heavy,  asymmetrical,  and  installed  in  areas  of  difficult  access. 

Task  Time  Estimator  Research  Program  Plan.  As  a  result  of  the  Air  Force's 
response  to  both  the  PDR  and  CDR,  UDRI  wrote  the  Research  Program  Plan  for  the  Task 
Time  Estimator  and  submitted  it  to  the  Air  Force  (Attch  1,  CDRL  Sequence  5).  This 
document  contains  guidelines  for  the  TTE  development,  results  of  time  study  research, 
description  of  proposed  research,  methods  for  developing  the  TTE  databases,  description  of 
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the  TTE  database  structure,  description  of  how  the  TTE  will  be  implemented,  and  a  plan  for 
validating  the  time-to-repair  estimated  computed  by  the  TTE. 

2.1.4  Perform  Research 


Time  Studies 

A  series  of  time  studies  were  conducted  to  investigate  the  effects  of  numerous 
variables  on  the  time  required  to  disassemble  and  reassemble  a  flange-type  pipe  fitting. 

Critical  elements  included  location  of  work  area,  accessibility  of  work  area,  types  of  tools  and 
tool  combinations  for  performing  the  task,  and  interference  levels. 

These  studies  utilized  the  same  basic  equipment  and  procedures,  differing  only  in  the 
specific  variables  and  combination  of  variables.  To  simplify  this  report,  the  general 
experimental  information  that  is  common  to  all  of  the  studies,  will  be  described  first. 
Information  unique  to  the  individual  studies  will  be  presented  separately. 

General  Information 


1.  Apparatus: 

a.  Test  Equipment:  The  workstation  simulated  an  aircraft  maintenance  task  in  which  a 
technician  must  attach  a  flange-type  pipe  coupling  (See  Figure  1).  This  coupling 
was  held  together  by  four  bolts  with  self-locking  nuts  and  was  attached  to  a  flexible 
rubber  hose  that  provided  some  resistance  when  aligning  the  coupling  for  bolt 
insertion.  The  workstation  was  equipped  with  an  optional  wall  barrier  that 
provided  interference  during  the  installation  and  removal  of  the  bolts. 

The  simulated  workstation  was  mounted  on  a  unistrut  frame  (8'  w  x  9'  h  x  4' d)  that 
was  adjustable  in  all  three  axes  (height,  fore  and  aft,  and  lateral).  This  allowed  the 
workstation  to  be  positioned  at  any  reasonable  location  relative  to  the  subject.  The 
frame  was  equipped  with  a  barrier  that  limited  the  subject's  forward  movements 
toward  the  workstation. 
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Figure  1 .  Simulated  Flange  Type  Pipe  Fitting 

Three  types  of  wrenches  were  used  for  the  removal  and  installation  of  the  coupling 
7/16"  Ratchet  wrench 
7/16"  Box-end  wrench 
7/16"  Open-end  wrench 

All  three  types  of  tools  were  used  on  the  bolt  heads;  however,  the  ratchet  wrench 
was  not  used  on  the  nut. 


b.  Data  Collection  System:  A  video  recording  system  was  the  primary  data  collection 
equipment  for  this  study.  The  system  consisted  of  a  camera,  monitor,  VCR,  and  an 
encoder/decoder.  The  encoder/decoder  is  a  locally  manufactured  device  that 
permits  the  experimenter  to  superimpose  tones  on  the  video  tape  with  a  hand-held 
switch.  The  tones  correspond  to  event  start  and  end  times.  After  each  data 
collection  session,  the  tones  were  transferred  from  the  video  tape  to  a  diskette  via  a 
computer  program  designed  to  decode  the  tones.  If  suspect  results  were 
encountered,  the  video  tapes  were  reviewed  and  times  were  recorded  with  a  hand¬ 
held  stopwatch. 

2.  Procedures:  All  subjects  were  screened  for  health  and  physical  fitness  prior  to 
acceptance.  Eleven  anthropometric  measurements  were  taken  on  each  subject.  The 
subjects  were  then  shown  how  to  perform  the  task  and  were  given  a  practice  trial  prior 
to  actual  data  collection. 

The  subjects  were  instructed  to  disassemble  the  flange  type  coupling,  removing  the 
bolts  in  a  specific  order.  Time  data  for  this  portion  of  the  task  were  broken  into  four 
elements  corresponding  to  the  complete  removal  of  each  nut  and  bolt.  The  reassembly 
required  the  subject  install  the  nuts  and  bolts  in  the  same  order  in  which  they  were 
removed.  This  portion  of  the  task  was  broken  down  into  the  following  ten  elements: 
1-4,  install  each  of  the  four  nuts  and  bolts  using  the  hands  only;  5,  obtain  the  wrenches 
and  position  them  on  the  first  nut  and  bolt;  6-9,  tighten  each  of  the  nuts  and  bolts  with 
the  wrenches;  and  10,  lay  wrenches  aside. 

Horizontal  Time  Studies 


A.  Time  Study  #5 

"An  Investigation  of  Time  To  Remove  and  Install  Flange-Type  Pipe  Coupling  with 
Various  Wrenches  and  with  Limited  and  Unlimited  Workspace" 

1 .  Objective:  The  objective  of  this  study  was  to  determine  the  effect  of  tool  type  and 
interference  on  the  time  required  to  remove  and  install  a  flange-type  pipe  coupling. 

2.  Apparatus:  The  access  opening  with  which  the  subject  had  to  reach  through  to 
perform  the  tasks  was  19.5"  x  19.5",  which  was  large  enough  to  accommodate  the 
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95th  percentile  male  reaching  to  shoulder  depth  with  no  visual  obstruction  (from 
MIL-STD  1472D).  The  workstation  was  equipped  with  an  optional  wall  barrier  that 
provided  interference  during  the  installation  and  removal  of  the  bolts. 


The  height  of  the  workstation  and  the  lower  edge  of  the  opening  was  49",  which 
corresponds  to  the  midpoint  between  the  5th  percentile  chest  height  for  females  and 
95th  percentile  chest  height  for  males.  The  workstation  was  9"  from  the  access 
opening  and  was  situated  directly  in  front  of  the  subject. 

3.  Method: 

a.  Subjects:  Forty-eight  subjects  (twenty-four  male  and  twenty-four  female),  age  18 
to  30,  were  used  in  this  study.  All  subjects  adequately  represented  the  Air  Force 
aircraft  maintenance  technician  in  body  size  (AFR  160-43)  and  weight  lift 
capability  (minimum  of  40  pounds  on  the  six-foot  incremental  weight  lift  test). 

b.  Varia^'  The  variables  for  this  study  were  as  follows: 

Dependent  variables: 

•  Time  to  complete  the  installation  or  removal  of  each  nut/bolt 
combination 

Independent  variables: 

Task  type 

•  Remove 

•  Install 

Interference  level 

•  No  interference  (no  wall  barrier) 

•  Interference  (wall  barrier  2"  to  the  left  of  the  pipe  flange  fitting) 

Tool  combination 

•  Ratchet  on  bolt,  box-end  on  nut 

•  Box-end  on  bolt,  box-end  on  nut 

•  Box-end  on  bolt,  open-end  on  nut 

•  Open-end  on  bolt,  box-end  on  nut 

•  Open-end  on  bolt,  open-end  on  nut. 
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This  created  a  2  x  2  x  5  factorial  consisting  of  20  different  combinations  of  the 
independent  variables.  Six  groups  of  eight  subjects  were  run  through  the  different 
combinations  of  variables. 


c.  Results:  Results  for  this  study  indicated  the  fastest  times  were  produced  with 
the  tool  combination  of  the  Ratchet  wrench  and  the  box-end  wrench.  Time 
increased  with  the  addition  of  the  interference  regardless  of  the  tool 
combination.  Table  1  presents  the  mean  total  task  time  for  assembling  and 
disassembling  the  flange  type  pipe  fitting  with  each  of  the  tool  combinations 
and  interference. 


Table  1.  Mean  Total  Task  Times  for  Assembling 
and  Disassembling  the  Flange  Type  Pipe 
Fitting  with  Each  of  the  Tool  Combinations 
and  Interference 


Assemble  Disassemble 


Tool  Type 

No  Interference 

Interference 

No  Interference 

Interference 

Rat  -  Box 

85.89 

110.62 

75.35 

99.92 

Box  -  Box 

121.20 

128.32 

115.10 

125.47 

Box  -  Open 

127.11 

152.87 

126.93 

152.46 

Open  -  Box 

131.80 

170.85 

122.81 

147.32 

Open  -  Open 

134.77 

170.34 

125.21 

144.53 

28 


B  Time  Study  #6 


"An  Investigation  of  Time  To  Remove  and  Install  Flange-Type  Pipe  Coupling  with 
Various  Wrenches  and  with  Limited  and  Unlimited  Workspace" 

1 .  Objective:  The  objective  of  this  study  was  to  determine  the  effect  of  tool  type  and 
interference  on  the  time  required  to  remove  and  install  a  flange-type  pipe  coupling. 
This  study  was  a  continuation  of  Time  Study  #5. 

2.  Apparatus:  The  access  opening  with  which  the  subject  had  to  reach  through  to 
perform  the  tasks  was  8"  x  5",  which  is  the  minimum  access  opening  size  allowed  by 
MIL-STD  1472D  for  work  requiring  the  use  of  two  hands  but  with  no  visual  access. 

The  height  of  the  workstation  and  the  lower  edge  of  the  opening  was  49",  which 
corresponds  to  the  midpoint  between  the  5th  percentile  chest  height  for  females  and 
95th  percentile  chest  height  for  males.  The  workstation  was  9"  from  the  access 
opening  and  was  situated  directly  in  front  of  the  subject. 

3.  Method: 

a.  Subjects:  Forty-eight  subjects  (24  male  and  24  female),  age  18  to  30,  were  run  in 
this  study.  All  subjects  adequately  represented  the  Air  Force  aircraft  maintenance 
technician  in  body  size  (AFR  160-43)  and  weight  lift  capability  (minimum  of  40 
pounds  on  the  six-foot  incremental  weight  lift  test). 

b.  Variables:  The  variables  for  this  study  were  as  follows: 

Dependent  variables: 

•  Time  to  complete  the  installation  or  removal  of  each  nut/bolt 
combination 

Independent  variables: 

Task  type 

•  Remove 

•  Install 

Interference  level 

•  No  interference  (no  wall  barrier) 
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•  Interference  (wall  barrier  2"  to  the  left  of  the  pipe  flange  fitting) 

Tool  combination 

•  Ratchet  on  bolt,  box-end  on  nut 

•  Box-end  on  bolt,  box-end  on  nut 

•  Open-end  on  bolt,  box-end  on  nut 

•  Box-end  on  bolt,  open-end  on  nut 

•  Open-end  on  bolt,  open-end  on  nut. 

c.  Results:  Results  indicated  that  significantly  more  time  was  required  to 

complete  the  task  with  the  8"  x  5"  opening  in  place.  Table  2  presents  the  mean 
total  task  time  for  assembling  and  disassembling  the  flange  type  pipe  fitting 
with  each  of  the  tool  combinations  and  interference. 

Table  2.  Mean  Total  Task  Times  for  Assembling 
and  Disassembling  the  Flange  Type  Pipe 
Fitting  with  Each  of  the  Tool  Combinations 
and  Interference 


Assemble  Disassemble 


Tool  Type 

No  Interference 

Interference 

No  Interference 

Interference 

Rat  -  Box 

121.10 

150.24 

120.09 

137.42 

Box  -  Box 

165.38 

198.01 

170.23 

196.61 

Box  -  Open 

161.59 

175.22 

148.37 

172.00 

Open  -  Box 

200.77 

254.53 

178.12 

217.06 

Open  -  Open 

195.55 

240.97 

193.29 

225.59 
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Vertical  Time  Studies 


A.  Time  Study  #7 

"An  Investigation  of  Time  to  Remove  and  Install  an  Overhead  Flange-Type  Pipe 
Coupling  with  Various  Wrenches  with  Limited  and  Unlimited  Workspace" 

1 .  Objective:  The  objective  of  this  study  was  to  determine  the  effect  of  tool  type  and 
interference  on  the  time  required  to  remove  and  install  a  flange-type  pipe  coupling. 

This  study  was  a  continuation  of  Time  Studies  5  and  6.  In  those  studies,  the 
workstation  with  the  flange-type  pipe  coupling  was  located  at  chest  height,  directly  in 
front  of  the  subject  while  in  this  study,  the  workstation  was  located  overhead. 

2.  Apparatus:  The  workstation  was  mounted  80  inches  above  the  floor  and  was 
accessible  through  a  19.5"  x  19.5"  access  opening,  which  was  large  enough  to 
accommodate  the  95th  percentile  male  reaching  to  shoulder  depth  with  no  visual 
obstruction  (from  MEL-STD  1472D). 

3.  Method: 

a.  Subjects:  Twenty-four  subjects  (12  male  and  12  female),  age  18  to  30,  were  run  in 
this  study.  All  subjects  adequately  represented  the  Air  Force  aircraft  maintenance 
technician  in  body  size  (AFR  160-43)  and  weight  lift  capability  (minimum  of  40 
pounds  on  the  six-foot  incremental  weight  lift  test). 

b.  Variables:  The  variables  for  this  study  were  as  follows: 

Dependent  variables: 

•  Time  to  complete  the  installation  or  removal  of  each  nut/bolt 
combination 

Independent  variables: 

Task  type 

•  Remove 

•  Install 
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Interference  level 


•  No  interference  (no  wall  barrier) 

•  Interference  (wall  barrier  2"  to  the  left  of  the  pipe  flange  fitting) 

Tool  combination 

•  Ratchet  on  bolt,  box-end  on  nut 

•  Open-end  on  bolt,  open-end  on  nut. 

There  were  four  groups  of  six  subjects.  Two  of  the  groups  were  tested  entirely 
with  one  of  the  tool  combinations,  performing  three  trials  with  each  interference 
level.  The  remaining  two  groups  used  both  tool  combinations,  based  on 
interference  level.  One  group  used  the  ratchet-box  combination  without 
interference  and  the  open-open  combination  with  interference  while  the  other 
group  used  the  ratchet-box  combination  with  interference  and  the  open-open 
combination  without  interference. 

c.  Results:  Table  3  presents  the  mean  total  task  time  for  assembling  and 

disassembling  the  flange  type  pipe  fitting  with  each  of  the  tool  combinations  and 
interference. 

Table  3.  Mean  Total  Task  Times  for  AssemI" 
and  Disassembling  the  Flange  Type  ^ 

Fitting  with  Each  of  the  Tool  Combinations 
and  Interference. 


Assemble  Disassemble 


Tool  Type 

No  Interference 

Interference 

No  Interference 

Interference 

Rat  -  Box 

107.00 

124.54 

100.02 

120.19 

Open  -  Open 

156.07 

204.87 

140.92 

173.97 

B.  Time  Study  #8 

"An  Investigation  of  Time  to  Remove  and  Install  an  Overhead  Flange-Type  Pipe 
Coupling  with  Various  Wrenches  with  Limited  and  Unlimited  Workspace" 
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1 .  Objective:  The  objective  of  this  study  was  to  determine  the  effect  of  tool  type  and 
interference  on  the  time  required  to  remove  and  install  a  flange-type  pipe  coupling. 

This  study  was  a  continuation  of  the  previous  time  studies.  In  those  studies,  the 
workstation  with  the  flange-type  pipe  coupling  was  located  either  at  chest  height, 
directly  in  front  of  the  subject  (Time  Studies  5  and  6)  or  the  workstation  was  located 
overhead  unlimited  access  (Time  Study  7).  In  the  current  study,  the  subjects 
performed  an  identical  task  while  reaching  overhead  through  and  8"  x  5"  access 
opening. 

2.  Apparatus:  The  workstation  was  mounted  80"  above  the  floor  and  was  accessible 
through  an  8"  x  5"  access  opening,  which  corresponds  to  the  minimum  width  allowed 
by  MIL- STD  1472D  for  reaching  half  arms-length  (hand  to  elbows)  with  both  arms. 
The  access  opening  was  cut  in  the  center  of  a  piece  of  plywood  and  placed  8"  below 
the  workstation,  creating  a  ceiling  of  72".  The  opening  was  centered  on  the  task 
fixture  and  could  be  removed  easily  for  installation  and  removal  of  the  interference 
barrier. 

3.  Method: 

a.  Subjects:  Twenty-four  subjects  (12  male  and  12  female),  age  18  to  30,  were  run  in 
this  study.  All  subjects  adequately  represented  the  Air  Force  aircraft  maintenance 
technician  in  body  size  (AFR  160-43)  and  weight  lift  capability  (minimum  of  40 
pounds  on  the  six-foot  incremental  weight  lift  test). 

b.  Variables:  The  variables  for  this  study  were  as  follows: 

Dependent  variables: 

•  Time  to  complete  the  installation  or  removal  of  each  nut/bolt 
combination 

Independent  variables: 

Task  type 

•  Remove 

•  Install 

Interference  level 

•  No  interference  (no  wall  barrier) 
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•  Interference  (wall  barrier  2"  to  the  left  of  the  pipe  flange  fitting) 
Tool  combination 

•  Ratchet  on  bolt,  box-end  on  nut 

•  Open-end  on  bolt,  open-end  on  nut. 

There  were  four  groups  of  six  subjects.  Two  of  the  groups  were  tested  entirely 
with  one  of  the  tool  combinations,  performing  three  trials  with  each  interference 
level.  The  remaining  two  groups  used  both  tool  combinations,  based  on 
interference  level.  One  group  used  the  ratchet-box  combination  without 
interference  and  the  open-open  combination  with  interference  while  the  other 
group  used  the  ratchet-box  combination  with  interference  and  the  open-open 
combination  without  interference. 

c.  Results:  Table  4  presents  the  mean  total  task  time  for  assembling  and 

disassembling  the  flange  type  pipe  fitting  with  each  of  the  tool  combinations 
and  interference. 

Table  4.  Mean  Total  Task  Time  for  Assembling 
and  Disassembling  the  Flange  Type  Pipe 
Fitting  with  Each  of  the  Tool  Combinations 
and  Interference 

Assemble  Disassemble 


Tool  Type 

No  Interference 

Interference 

No  Interference 

Interference 

Rat  -  Box 

141.07 

145.86 

131.07 

140.36 

Open  -  Open 

209.24 

282.73 

205.08 

257.29 

C.  Time  Study  #9 

"An  Investigation  of  Time  to  Remove  and  Install  an  Overhead  Flange-Type  Pipe 
Coupling  with  Various  Wrenches  with  Limited  and  Unlimited  Workspace" 
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1 .  Objective:  The  objective  of  this  study  was  to  determine  the  effect  of  tool  type  and 
interference  on  the  time  required  to  remove  and  install  a  flange-type  pipe  coupling. 

This  study  was  a  continuation  of  the  previous  time  studies.  In  those  studies,  the 
workstation  with  the  flange-type  pipe  coupling  was  located  either  at  chest  height, 
directly  in  front  of  the  subject  (Time  Studies  5  and  6),  overhead  with  unlimited  access 
(Time  Study  7),  or  overhead  with  limited  access  (Time  Study  8).  In  the  current 
study,  the  subjects  performed  the  identical  task  while  reaching  overhead  with 
unlimited  and  limited  access  and  at  various  ceiling  heights. 

2.  Apparatus:  The  unistrut  frame  was  adjusted  to  create  six  different  ceiling  heights  (2', 
3',  4',  5',  and  18").  The  workstation  was  mounted  8"  above  these  heights  and  was 
accessible  through  both  an  8"  x  5"  access  opening  (limited  access),  which 
corresponds  to  the  minimum  width  allowed  by  MIL-STD  1472D  for  reaching  half 
arms-length  (hand  to  elbows)  with  both  arms,  and  a  19.5"  x  19.5"  access  opening 
which  was  large  enough  to  accommodate  the  95th  percentile  male  reaching  to 
shoulder  s  with  no  visual  obstruction  (from  MIL-STD  1472D).  The  8"  x  5" 
access  opening  was  cut  in  the  center  of  a  piece  of  plywood  and  was  centered  on  the 
task  fixture. 

3.  Method: 

a.  Subjects:  Two  hundred  forty  subjects  (120  male  and  120  female),  age  18  to  30, 
were  run  in  this  study.  Since  each  ceiling  height  was  performed  as  a  separate 
study,  the  subjects  were  divided  into  five  groups  of  48  (24  male  and  24  female). 

All  subjects  adequately  represented  the  Air  Force  aircraft  maintenance  technician 
in  body  size  (AFR  160-43)  and  weight  lift  capability  (minimum  of  40  pounds  on 
the  six-foot  incremental  weight  lift  test). 

b.  Variables:  The  variables  for  this  study  were  as  follows: 

Dependent  variables: 

•  Time  to  complete  the  installation  or  removal  of  each  nut/bolt 
combination 
Independent  variables: 

Access  opening  size 
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.  Limited  (8"  x  5") 

•  Unlimited  (19.5"  x  19.5") 

Interference  level 

•  No  interference  (no  wall  barrier) 

•  Interference  (wall  barrier  2"  to  the  left  of  the  pipe  flange  fitting) 

Tool  combination 

•  Ratchet  on  bolt,  box-end  on  nut 

•  Open-end  on  bolt,  open-end  on  nut. 

Ceiling  height  (between-group  variable) 

•  60  inches 

•  48  inches 

•  36  inches 

•  24  inches 

•  15  inches 

There  were  eight  groups  of  six  subjects  for  the  24  and  35  inch  ceiling  heights. 
Subjects  in  each  group  performed  three  trials  each  on  two  of  the  eight  possible 
tool  combinations  (2),  interference  levels  (2),  and  access  opening  size  (2) 
conditions.  The  order  of  the  six  remove/install  trials  are  counter  balanced  within 
each  group.  For  the  15,  48  and  60  inch  ceiling  heights  there  were  3  groups  of  6 
subjects.  Subjects  in  each  of  these  groups  performed  three  trials  each  on  2  of  the  3 
following  experimental  conditions:  1)  Ratchet  and  boxed-end  wrenches, 
unrestricted  assess,  and  no  interference,  2)  Two  open-end  wrenches,  restricted 
access,  and  No  interference,  and  3)  Two  open-end  wrenches,  restricted  access, 
with  interference. 

c.  Results:  Table  5  presents  the  mean  total  task  times  for  assembling  and 
disassembling  the  flange  type  pipe  fitting  for  each  of  the  five  ceiling  heights. 
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Table  5.  Mean  Total  Task  Time  for  Assembling 
and  Disassembling  the  Flange  Type  Pipe 
Fitting  for  Each  of  the  Five  Ceiling  Heights 

15  inch  Ceiling 


Tool  Type 

Interference 

Opening  Size 

Install 

Remove 

Rat  -  Box 

No 

19.5x19.5 

131.14 

124.02 

Open  -  Open 

No 

8x5 

297.86 

284.51 

Open  -  Open 

Yes 

8x5 

386.78 

386.42 

24  inch  Ceiling 

Tool  Type 

Interference 

Opening  Size 

Install 

Remove 

Rat  -  Box 

No 

19.5  x  19.5 

170.37 

142.47 

Rat  -  Box 

Yes 

19.5x19.5 

195.21 

179.49 

Rat  -  Box 

No 

8x5 

203.58 

187.83 

Rat  -  Box 

Yes 

8x5 

254.95 

213.86 

Open  -  Open 

No 

19.5x19.5 

315.93 

316.14 

Open  -  Open 

Yes 

19.5x19.5 

325.46 

325.02 

Open  -  Open 

No 

8x5 

396.86 

377.48 

Open  -  Open 

Yes 

8x5 

493.89 

369.46 
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36  inch  Ceiling 


Tool  Type 

Interference 

Opening  Size 

Install 

Remove 

Rat  -  Box 

No 

19.5  x  19.5 

112.87 

103.37 

Rat  -  Box 

Yes 

19.5  x  19.5 

129.99 

122.78 

Rat  -  Box 

No 

8x5 

186.88 

171.02 

Rat  -  Box 

Yes 

8x5 

197.73 

178.01 

Open  -  Open 

No 

19.5  x  19.5 

174.95 

159.86 

Open  -  Open 

Yes 

19.5  x  19.5 

229.09 

195.44 

Open  -  Open 

No 

8x5 

260.81 

234.62 

Open  -  Open 

Yes 

8x5 

303.72 

268.95 

48  inch  Ceiling 

Tool  Type 

Interference 

Opening  Size 

Install 

Remove 

Rat  -  Box 

No 

19.5  x  19.5 

117.41 

108.70 

Open  -  Open 

No 

8x5 

199.40 

180.64 

Open  -  Open 

Yes 

8x5 

261.15 

259.87 
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60  inch  ceiling 


Tool  Type 

Interference 

Opening  Size 

Install 

Remove 

Rat  -  Box 

No 

19.5  x  19.5 

134.20 

119.50 

Open  -  Open 

No 

8x5 

310.12 

274.15 

Open  -  Open 

Yes 

8x5 

332.58 

352.17 

Hand  Clearance  Studies 

Two  studies  were  performed  to  determine  the  effect  of  hand  clearance  and  accessibility  on 
the  time  to  install  and  remove  a  fastener  with  the  hands  only.  No  tools  were  involved  in 
this  study.  The  studies  were  identical  with  the  exception  of  the  access  opening  size.  For 
this  reason,  all  of  the  general  experimental  information  will  be  presented  first,  with  the 
specific  apparatus  differences  and  results  following.  The  two  access  openings  tested  were 
the  unrestricted  access  (19.5"  x  19.5"  opening)  and  the  restricted  access  (8"  x  5"). 

1.  Objective:  The  objective  of  this  study  was  to  determine  the  effect  of  nut  size,  bolt 
size,  and  hand  clearance  on  the  time  to  remove  and  install  an  individual  nut  or  bolt. 

2.  Apparatus: 

a.  Test  Equipment:  The  workstation  simulated  an  aircraft  maintenance  task  in  which 
a  technician  must  install  or  remove  a  fastener  by  hand.  Access  to  the  work  area 
was  accomplished  through  either  a  19.5"  x  19.5"  opening  or  an  8"  x  5"  opening. 
The  installation  point  of  the  nut  or  bolt  was  located  8"  from  the  opening. 

The  workstation  was  mounted  on  a  unistrut  frame  that  had  adjustments  in  all  three 
axes  (height,  fore  and  aft,  and  lateral).  This  allowed  the  workstation  to  be 
positioned  at  any  reasonable  location  relative  to  the  subject.  The  fixture  plate  was 
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oriented  in  six  different  directions  in  this  study.  The  access  opening  was  49"  above 
the  floor  and  was  centered  directly  in  front  of  the  work  area. 


The  workstation  was  equipped  with  a  movable  wall  barrier  and  a  plate  fixture  onto 
which  the  nut  or  bolt  was  to  be  installed.  The  installation  point  of  the  fastener  was 
centered  on  the  plate,  which  required  an  additional  4.5"  of  reach. 

b.  Data  Collection  System:  A  video  recording  system  was  the  primary  data  collection 
equipment  for  this  study.  The  system  consisted  of  a  camera,  monitor,  VCR,  and 
an  encoder/decoder.  The  encoder/decoder  is  a  locally  manufactured  device  that 
permits  the  experimenter  to  superimpose  tones  on  the  video  tape  with  a  hand-held 
switch.  The  tones  correspond  to  event  start  and  end  times.  After  each  data 
collection  session,  the  tones  were  transferred  from  the  video  tape  to  a  diskette  via 
a  computer  program  designed  to  decode  the  tones.  If  suspect  results  were 
encountered,  the  video  tapes  were  reviewed  and  times  were  recorded  with  a  hand¬ 
held  stopwatch. 

c.  Procedures:  All  subjects  were  screened  for  health  and  physical  fitness  prior  to 
acceptance.  Ten  anthropometric  measurements  were  t?  i  each  subject.  The 
subjects  were  then  shown  how  to  perform  the  task  and  were  given  a  practice  trial. 
The  subjects  were  instructed  to  install  the  nut  or  bolt  and  then  remove  the  fastener 
and  were  given  several  practice  trials  prior  to  beginning  the  test  session. 

Unrestricted  Access  Hand  Clearance 


3.  Method: 

a.  Subjects:  Sixty  subjects  (thirty  male  and  thirty  female),  age  18  to  30,  were  run  in 
this  study.  Since  each  task  orientation  was  performed  as  a  separate  study,  the 
subjects  were  divided  into  six  groups  of  ten  (five  male  and  five  female).  All 
subjects  adequately  represented  the  Air  Force  aircraft  maintenance  technician  in 
body  size  (AFR  160-43). 
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b.  Variables:  The  variables  for  this  study  were  as  follows: 


Dependent  variables: 

•  Time  to  complete  the  installation  or  removal  of  each  nut  and  bolt. 
Independent  variables: 

Task  Orientation 

•  Facing  -  Front 

•  Facing  -  Back 

•  Transverse  -  Right 

•  Transverse  -  Left 

•  Vertical  -  Top 

•  Vertical  -  Bottom 
Fastener  Type 

•  Bolt 

•  Nut 

Fastener  Size 
.  1/4 
.  1/2 

Barrier  Clearance 

•  1  inch 

•  1.5  inches 

•  2  inches 

•  3  inches 

Task  orientation  was  a  between  group,  with  ten  subjects  per  group.  Subjects  in 
each  group  performed  three  trials  of  each  sixteen  possible  conditions  (2  fastener 
types  ,  2  fastener  sizes,  4  barrier  clearances). 

c.  Results:  The  means  for  all  six  groups  were  compared  to  determine  whether 
differences  existed  between  the  six  orientations  tested  in  this  study.  The  fastest 
times  overall  occurred  in  the  removal  of  the  1/4"  nut  condition  for  all  groups.  The 
slowest  times  overall  occurred  in  the  installation  of  the  1/2"  bolt  conditions.  For 
all  groups  and  all  conditions,  there  was  no  significant  difference  in  performance 
times  beyond  the  2.0"  clearance  barrier  level. 

Performance  times  among  the  six  orientations  did  not  differ  to  a  great  extent; 
however,  the  slowest  times  appeared  to  occur  in  groups  5  and  6  (facing  front  and 
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facing  back).  The  remaining  four  groups  (transverse  left  and  right,  vertical  and 
down)  did  not  show  any  substantial  differences  between  the  performance  times  in 
the  various  conditions. 


For  this  reason,  only  groups  5  and  6  were  selected  to  be  tested  in  the  follow-on 
restricted  access  opening  study.  Group  5  was  tested  first  since  this  group 
produced  the  overall  slowest  times.  The  mean  installation  and  removal  times  are 
presented  in  Table  6. 

Table  6.  Mean  Installation  and  Removal  Times  for 
Unrestricted  Access  Hand  Clearance 


Group  1.  Transverse  Right  Orientation 

Install  Remove 


1.5” 

2.0" 

2.5M 

3.0” 

1.5" 

2.0" 

2.5" 

3.0" 

1/4  Nut 

15.41 

8.43 

6.91 

5.92 

10.64. 

6.63 

6.15 

5.59 

1/4  Bolt 

43.07 

15.00 

9.65 

9.21 

34.22 

10.04 

7.30 

6.77 

1/2  Nut 

18.44 

.84 

7.21 

6.86 

15.19 

10.34 

8.60 

8.23 

1/2  Bolt 

59.49 

30.17 

18.08 

18.06 

28.02 

13.37 

10.82 

10.05 
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Group  2.  Vertical  Up  Orientation 


Install  Remove 


1.5" 

2.0" 

2.5" 

3.0" 

1.5" 

2.0" 

2.5" 

3.0" 

1/4  Nut 

18.69 

11.06 

6.25 

5.55 

9.30 

6.71 

5.60 

4.79 

1/4  Bolt 

30.33 

15.44 

9.74 

8.43 

34.27 

9.86 

7.33 

7.07 

1/2  Nut 

16.21 

9.67 

6.52 

6.12 

13.87 

9.69 

8.28 

6.99 

1/2  Bolt 

48.95 

30.37 

17.48 

14.01 

28.01 

13.32 

9.74 

9.23 

Group  3. 

Transverse  ’ 

Orientation 

Install 

Remove 

1.5" 

2.0” 

2.5" 

3.0" 

1.5" 

2.0" 

2.5" 

3.0" 

1/4  Nut 

20.59 

12.36 

6.87 

6.88 

12.24 

9.01 

7.77 

7.29 

1/4  Bolt 

37.46 

18.44 

10.71 

10.25 

27.67 

10.26 

8.64 

7.79 

1/2  Nut 

22.55 

12.23 

7.75 

6.72 

18.33 

13.21 

11.51 

11.46 

1/2  Bolt 

81.41 

69.62 

25.10 

23.36 

21.55 

13.11 

11.10 

11.13 
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Group  4.  Vertical  Down  Orientation 


Install  Remove 


1.5" 

2.0" 

2.5" 

3.0" 

1.5" 

2.0" 

2.5" 

3.0" 

1/4  Nut 

26.13 

16.31 

8.24 

7.69 

11.01 

7.29 

5.45 

5.32 

1/4  Bolt 

38.88 

32.02 

13.16 

13.01 

35.61 

11.60 

7.64 

7.65 

1/2  Nut 

34.77 

16.16 

9.24 

7.51 

12.77 

9.29 

7.07 

6.76 

1/2  Bolt 

51.37 

31.09 

20.20 

17.54 

33.11 

15.40 

9.86 

9.59 

Group  5.  Facing  Front  Orientation 


Install  Remove 


1.5" 

2.0" 

2.5" 

3.0" 

1.5" 

2.0" 

2.5" 

3.0’ 

1/4  Nut 

21.46 

13.50 

8.34 

7.55 

14.02 

9.66 

7.71 

7.49 

1/4  Bolt 

47.64 

24.56 

17.27 

13.26 

46.19 

15.30 

13.70 

11.76 

1/2  Nut 

22.97 

12.59 

8.29 

8.37 

23.76 

15.99 

13.55 

12.17 

1/2  Bolt 

58.00 

31.96 

23.52 

23.42 

36.32 

17.80 

15.84 

14.81 
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Group  6.  Facing  Away  Orientation 


Install  Remove 


1.5" 

2.0M 

2.5" 

3.0" 

1.5" 

2.0" 

2.5" 

3.0" 

1/4  Nut 

22.24 

17.59 

10.44 

8.31 

14.58 

10.12 

8.49 

8.18 

1/4  Bolt 

41.57 

22.37 

14.54 

13.28 

51.20 

18.73 

9.45 

9.05 

1/2  Nut 

22.37 

17.05 

12.31 

11.97 

1/2  Bolt 

49.91 

26.15 

19.84 

16.96 

34.67 

16.99 

12.12 

11.41 

Restricted  Access  Hand  Clearance 


This  study  was  a  follow-on  to  the  unlimited  access  hand  clearance  study.  The  access 
opening  was  reduced  to  8"  x  5"  to  create  a  restricted  access  opening.  Initially,  only 
one  group  of  subjects  was  tested  to  determine  if  it  was  going  to  be  necessary  to 
duplicate  the  entire  study.  Since  the  slowest  performance  times  in  the  unrestricted 
access  portion  of  the  study  were  in  the  Facing  Orientation,  this  group  was  tested  first 
to  determine  if  any  significant  differences  existed  between  the  large  and  small  access 
openings.  Analysis  indicated  significant  differences  in  this  group,  suggesting  the  need 
to  test  the  next  slowest  group  from  the  unrestricted  portion  of  the  study.  No 
significant  differences  between  the  two  access  opening  times  were  evident  in  this 
group  and  further  data  collection  was  postponed. 

a.  Subjects:  Twenty  subjects  (ten  male  and  ten  female),  age  18  to  30,  were  run  in 
this  study.  Since  each  task  orientation  was  performed  as  a  separate  study,  the 
subjects  were  divided  into  two  groups  of  ten  (five  male  and  five  female).  All 
subjects  adequately  represented  the  Air  Force  aircraft  maintenance  technician  in 
body  size  (AFR  160-43). 
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b.  Variables:  The  variables  for  this  study  were  as  follows: 


Dependent  variables: 

•  Time  to  complete  the  installation  or  removal  of  each  nut  and  bolt. 

Independent  variables: 

Task  Orientation 

•  Facing  -  Front 

•  Facing  -  Back 

Fastener  Type 

•  Bolt 

•  Nut 

Fastener  Size 

.  1/4 

.  1/2 

Barrier  Clearance 

•  1  inch 

•  1.5  inches 

•  2  inches 

•  3  inches 

Task  orientation  was  a  between  group,  with  ten  subjects  per  group.  Subjects  in 
each  group  performed  three  trials  of  each  sixteen  possible  conditions  (two  fastener 
types,  two  fastener  sizes,  and  four  barrier  clearances). 

d.  Results:  Analysis  of  Variance  (ANOVA)  were  run  on  these  data.  Original 
analysis  of  the  Group  5  data  revealed  a  significant  interaction  of  the  "Study  x 
Clearance"  variables.  However,  an  unexpected  and  unusual  result  prompted 
further  investigation.  This  result  indicated  that  the  removal  times  for  the 
unrestricted  access  conditions  were  an  average  of  seven  seconds  slower  than  those 
in  the  restricted  access  conditions.  Since  this  result  was  evident  in  only  one 
condition  (the  1.5"  clearance  level  which  was  considered  the  most  difficult),  the 
raw  data  printouts  and  videotapes  were  studied  to  determine  the  circumstances  of 
this  result.  The  investigation  revealed  several  anomalies  with  the  data.  The  most 
serious  was  the  inability  to  complete  the  1.5"  clearance  conditions  for  5  of  the  10 
subjects.  It  was  determined  that  it  would  be  necessary  to  run  5  additional  subjects 
through  all  conditions. 
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Although  performance  times  in  the  1.5"  clearance  barrier  condition  were  still 
higher  for  the  Remove  unrestricted  conditions,  these  results  were  no  longer 
significant.  A  graphic  comparison  of  the  means  of  these  two  groups  shows  the 
slowest  performance  times  to  occur  in  the  1/4"  and  1/2"  bolt  conditions  at  the  1.5" 
clearance  barrier  level.  This  was  also  true  for  the  installation  performance  times. 
ANOVA  results  indicated  both  bolt  size  conditions  to  be  significantly  different 
slower  than  the  nut  installation  times. 

ANOVA  results  for  Group  6  (Facing  Back)  revealed  a  significant  difference 
between  the  two  access  opening  groups  in  the  Remove  conditions  only.  A 
significant  interaction  was  also  evident  for  "Study  x  Clearance"  variables.  A 
Tukey  post  hoc  revealed  the  significant  difference  to  occur  between  the  two 
studies  at  the  1.5"  clearance  barrier  only.  These  times  were  significantly  different 
than  all  other  times  also  (Restricted  and  Unrestricted  at  2.0"  ,  2.5",  and  3.0" 
clearance  levels). 

A  comparison  of  the  means  revealed  the  slowest  performance  times  to  occur  for 
both  the  1/4"  and  1/2"  bolts  at  the  1.5"  barrier  clearance  level  in  both  the 
installation  and  removal  tasks.  Only  minor  differences  in  performance  times  were 
evident  for  the  other  conditions. 

The  mean  installation  and  removal  times  are  presented  in  Table  7. 

Table  7.  Mean  Installation  and  Removal  Times 
for  Restricted  Access  Hand  Clearance 


Facing  Front  Orientation 


Install 


Remove 


1.5" 

2.0" 

2.5" 

3.0" 

1.5" 

2.0" 

2.5" 

3.0" 

1/4  Nut 

40.89 

16.16 

10.21 

10.37 

15.17 

10.99 

9.78 

9.28 

1/4  Bolt 

62.57 

30.98 

20.99 

19.52 

44.13 

23.08 

15.56 

14.17 
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1/2  Nut 

31.24 

15.45 

12.37 

10.96 

22.63 

18.38 

15.29 

14.43 

1/2  Bolt 

63.51 

32.69 

26.94 

26.75 

34.91 

21.80 

18.21 

16.64 

Facing  Away  Orientation 

Install 


1.5" 

2.0" 

2.5" 

1/4  Nut 

28.22 

17.57 

11.11 

1/4  Bolt 

51.67 

28.39 

16.98 

1/2  Nut 

37.66 

17.24 

11.14 

1/2  Bolt 

62.54 

30.31 

22.27 

Remove 


3.0" 

1.5" 

2.0" 

2.5" 

3.0" 

10.60 

17.04 

11.26 

9.53 

8.92 

15.29 

56.44 

16.26 

11.58 

10.99 

10.85 

26.99 

19.35 

14.17 

13.84 

20.07 

50.47 

19. J 

14.67 

13.88 

Vision  Study 

The  visibility  of  air  crew  and  ground  crew  members  can  be  limited  by  the  head  gear 
that  they  are  required  to  wear  during  the  performance  of  their  duties.  COMB  EUAN  displays 
visibility  plots  for  air  crews  and  CREW  CHIEF  displays  visibility  plots  for  ground  crews.  As 
new  head  gear  is  introduced  into  the  Air  Force,  new  studies  are  required  so  that  visibility  data 
can  be  modeled  and  included  in  the  appropriate  human  model  program. 

Objective:  The  purpose  of  this  study  was  to  collect  this  visibility  data  to  determine  the 
peripheral  vision  limits  of  Air  Force  personnel  while  wearing  the  following  equipment: 

MCU-2/P  Ground  crew  chemical  defense  mask 
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MBU-12/P  Air  crew  respirator  with  HGU-153/P  helmet 
MBU-19/P  Air  crew  chemical  defense  mask  with  HGU- 153/P  helmet 
Apparatus: 

1.  Moving  target  with  two  degrees  of  freedom  (azimuth  and  elevation).  The  target 
display  was  a  single  white  flashing  LED.  The  walls  behind  and  around  the  target  display  were 
covered  with  a  gray  photographic  background  paper  to  reduce  glare  and  provide  a 
background  void  of  any  detail  that  might  interfere  with  the  subject's  concentration  on  the 
target. 


2.  Adjustable  chair  with  head  rest.  The  chair  could  be  adjusted  horizontally  and 
vertically,  and  the  seat  back  angle  could  be  adjusted.  The  head  rest  could  be  adjusted  up  and 
down  and  back  and  forth. 

3.  Non-elastic  head  band  to  secure  the  head  to  the  head  rest  in  the  desired  position. 

4.  Mechanical  auditory  signaling  device,  for  subjects  to  use  to  signal  the  experimenter 
when  the  target  was  visible. 

5.  Head  Gear:  MCU-2/P  Ground  crew  chemical  defense  mask,  MBU- 12/P  Air  crew 
respirator,  MBU- 19/P  Air  crew  chemical  defense  mask,  and  HGU- 153/P  helmet. 

Method: 

Subjects.  The  subjects  were  ten  males  and  ten  females  between  the  ages  of  1 8  and  30. 
All  subjects  were  required  to  have  20/40  vision,  uncorrected. 

Procedure.  The  subject  is  placed  in  the  chair  so  that  the  sellion  landmark  (base  of  the 
nose,  between  the  eyes)  was  40.5  inches  from  the  target.  The  subject's  head  was  placed 
against  the  head  rest  with  the  frankfort  plane  (plane  established  by  the  three  points  of  the 
sellion  landmark  and  the  two  ear  openings)  parallel  to  the  floor.  The  chair  and  head  rest  were 
positioned  so  that  the  subject’s  sellion  landmark  coincided  with  the  intersection  of  the  azimuth 
and  elevation  axes  of  the  target.  The  head  was  secured  to  the  head  rest  with  a  head  band. 
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During  each  three  hour  test  session,  56  data  points  were  measured  in  each  of  the  head 
gear  conditions  and  in  a  baseline  condition  without  head  gear.  Each  point  was  measured 
twice;  first  by  moving  the  flashing  light  into  the  field  of  view  and  then  by  moving  the  flashing 
light  out  of  the  field  of  view.  The  following  points  were  measured: 

Top:  From  +80  to  -80  degrees  azimuth  in  10  degree  increments 

Sides:  From  +60  to  -60  degrees  elevation  in  10  degree  increments 

Bottom:  From  +60  to  -60  degrees  azimuth  in  10  degree  increments 

Results:  For  each  of  the  56  coordinates  that  were  measured  in  the  subject's  field  of  view,  two 
measurements  were  taken.  These  points  were  averaged  together  for  each  subject  and  each 
condition.  These  data  were  then  merged  and  averaged  across  all  subjects  and  plotted, 
resulting  in  one  average  plot  per  condition.  These  data  are  illustrated  in  Figures  2  through  5. 
The  average  data  were  then  converted  to  polar  coordinates.  For  each  condition,  the  points 
were  averaged  within  angular  coordinates  of  the  field  of  view  and  moving  averages  were 
calculated. 
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Elevation  (Degrees) 


Peripheral 


-80 

-150 


Azimuth  (Degrees) 


Figure  2.  Peripheral  Vision  Baseline 
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Pilot  Peripheral  Vision  Contours 


*  HGU  53/P 
°  MBU/19 

*  Baseline 


AZIMUTH  (Omym *) 


Figure  5.  Pilot  Peripheral  Vision  Contours 


Develop  TTE  Capabilities 


Paragraph  3. 1.1. 5  of  the  SOW  required  the  developing  of  an  enhancement  to  CREW 
CHIEF  for  computing  time-to-repair. 

The  Task  Time  Estimation  (TTE)  function  calculates  the  time  required  to  remove  and 
replace  individual  components  and  subsystems  within  a  proposed  design.  This  function  takes 
into  account  such  things  as  obstruction  caused  by  other  parts  of  the  system,  body  posture, 
clothing,  fatigue,  and  also  the  tools  being  used  (if  any).  In  addition,  while  the  TTE  does  not 
directly  calculate  times  for  related  tasks,  such  as  setup,  time  spent  retrieving  spare  parts,  and 
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troubleshooting,  it  does  allow  the  user  to  enter  these  values  into  the  TTE,  which  then  uses 
these  values  in  the  final  task  time  computations.  Unlike  other  Predetermined  Time  Systems, 
which  require  the  user  to  make  subjective  estimates  of  the  difficulty  of  a  task,  the  TTE 
objectively  estimates  task  difficulty,  and  the  times  output  reflect  this  difficulty. 

Much  of  the  data  behind  the  TTE  come  from  the  Elemental  Standard  Data  (ESD) 
database,  and  omni-level  MTM  database  developed  by  the  U.S.  Navy.  This  database  was 
expanded  to  take  into  account  clothing,  obstructions  in  the  workplace,  and  other  factors 
which  affect  task  time  in  the  workplace.  The  TTE  function  uses  this  database,  along  with  user 
input  and  workplace  geometry  to  calculate  time  for  virtually  all  remove  and  replace  tasks 
found  in  aircraft  maintenance. 

The  user  will  define  management  tasks  at  three  levels:  User  Element,  Task,  and 
Operation.  A  User  Element  is  the  lowest  level  maintenance  element,  and  consists  of  several 
user  elements  performed  in  a  specific  sequence,  and  usually  corresponds  to  a  single,  more 
complex  activity,  such  as  removing  an  access  panel.  An  Operation  consists  of  a  series  of 
tasks,  performed  in  a  specific  sequence,  and  usually  corresponds  to  a  complete  Remove  and 
Replace  maintenance  activity. 

The  actual  information  input  by  the  user  will  vary,  depending  on  the  level  at  which  he 
is  working.  The  user  can  begin  defining  a  particular  maintenance  activity  at  any  level,  and  any 
needed  lower  level  information  will  be  prompted  for  after  the  selected  level  is  input. 

A  User  Element  corresponds  to  a  simple,  discrete  maintenance  activity,  and  is  defined 
by  the  user  through  a  series  of  prompts  which  detail  the  activity  being  performed.  Through 
the  answers  to  these  prompts,  the  user  will  provide  tool  information,  fastener  information, 
object  information,  and  human  model  positioning  information. 

Maintenance  Tasks  are  defined  by  describing  the  exact  sequence  of  User  Elements 
which  comprise  the  Task.  Existing  User  Elements  are  displayed  in  a  menu,  and  the  user  may 
pick  from  these.  In  addition,  the  user  may  key-in  a  new  User  Element  name.  After  the 
definition  of  the  Task  is  complete,  the  user  will  automatically  be  prompted  to  define  any  new 
User  Elements  keyed-in  during  the  Task  definition.  Note  that  the  order  User  Elements  are 
defined  will  affect  the  overall  time,  so  they  must  be  defined  in  the  same  order  as  they  would  be 
performed  on  the  flightline. 

Maintenance  Operations  are  defined  by  describing  the  exact  sequence  of  maintenance 
tasks  which  comprise  the  Operation.  Existing  Tasks  are  displayed  in  a  menu,  and  the  user 
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may  pick  from  these.  In  addition,  the  user  may  key-in  a  new  Task  name.  After  the  definition 
of  the  Operation  is  complete,  the  user  will  automatically  be  prompted  to  define  any  new  Tasks 
keyed  in  during  the  Task  definition.  Note  that  the  order  Maintenance  Tasks  are  defined  will 
affect  the  overall  time,  so  they  must  be  defined  in  the  same  order  as  they  would  be  performed 
on  the  flightline. 

The  Task  Time  Estimation  Input/Output  (TIO)  subfunction  accesses  and/or  updates 
the  four  databases  needed  to  execute  the  Task  Time  Estimation  (TTE)  function.  The  TTE 
function  calculates  the  time  required  to  remove  and  replace  individual  components  and 
subsystems  within  a  proposed  design. 

The  lowest  level  database  is  the  Generic  Element  database.  This  database  contains  the 
basic  times  for  various  "types"  of  elements.  Currently,  the  only  type  available  is  the  threaded 
fastener  (bolt/screw)  type.  Other  types  will  be  added  to  the  database  as  data  become 
available.  The  information  to  drive  the  element  level  of  the  user  interface  is  contained  in  this 
database.  The  data  in  the  database  are  based  on  the  Elemental  Standard  Data  (ESD)  data  and 
data  collected  in  the  local  lab.  The  Generic  Element  database  can  only  be  accessed  or  read. 
This  database  will  not  be  updated  from  TIO. 

The  User  Element  database  contains  element  information  d  by  the  user.  The 
elements  correspond  to  a  simple,  discrete  maintenance  activity.  The  elements  consist  of  tool 
information,  fastener  information,  object  information,  and  human  modeling  positioning.  The 
TIO  subfunction  will  access  information  concerning  elements  previously  defined,  or  will  add 
new  user  elements  to  the  database.  Information  that  will  be  updated  or  retrieved  consists  of 
number  of  elements  in  the  database,  names  of  the  user  elements,  integers  representing  the 
variables  used  to  define  each  user  element  and  integers  that  identify  the  equation  needed  to 
define  the  time  unit  for  a  specific  user  element  combination.  Also  a  key  code  is  output  to  this 
database  that  corresponds  to  a  key  code  stored  in  the  generic  element  database. 

The  Task  database  contains  task  information  defined  by  the  user.  Each  task 
corresponds  to  a  sequence  of  user  elements.  Again,  the  TIO  subfunction  will  access 
information  concerning  tasks  previously  defined,  or  will  add  new  tasks  to  the  database. 
Information  that  will  be  updated  or  retrieved  consists  of  the  number  of  tasks  defined  in  the 
database,  name  of  each  task,  number  of  elements  that  compose  each  task  and  identification 
numbers  linking  the  elements  defined  in  the  User  Element  database  to  the  tasks  defined. 
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The  final  database  is  the  Operations  database  which  contains  operation  information 
defined  by  the  user.  Each  operation  corresponds  to  a  sequence  of  tasks.  This  information 
consists  of  the  number  of  operations  defined  in  the  database,  name  of  each  operation,  number 
of  tasks  that  compose  each  operation  and  identification  numbers  linking  the  tasks  defined  in 
the  Task  database  to  the  operations  defined.  The  TIO  subfunction  will  access  information 
concerning  operations  previously  defined,  or  will  add  new  operations  to  the  Operation 
database. 

The  interface  to  any  CAD  system  is  done  in  the  standard  PROMPT,  ACTION, 
RESULT  format.  The  user  is  faced  with  the  choice  of  defining  an  Operation,  Task,  or  User 
Element.  At  the  Operation  level,  the  user  is  prompted  to  define  tasks  that  make  up  this 
particular  operation.  The  user  can  choose  from  existing  tasks  from  the  task  database  or  can 
define  new  tasks.  In  the  same  manner,  the  user  can  define  a  task  consisting  of  previously 
defined  elements  (from  the  User  Element  database)  or  can  define  new  tasks.  At  the  User 
Element  level,  the  user  defines  the  specifics  of  each  User  Element.  These  specifics  include 
prompting  the  user  to  define  tool  information,  fastener  information,  object  information,  and 
human  model  positioning  information. 


2.1.6  Validate  the  Task  Time  Estimator 

UDRI  performed  time  study  research  to  validate  existing  data  and  developed  a  plan  for 
validating  the  Task  Time  Estimator  time-to-repair  estimates. 

Validation  of  Existing  Data.  Much  of  the  research  performed  by  UDRI  was 
designed  to  validate  data  obtained  from  the  ESD  database,  as  well  as  provide  additional  data 
for  the  TTE  database.  The  first  of  these  studies  was  designed  specifically  to  test  the  validity 
of  the  Navy's  Elemental  Standard  Data  database.  The  task  studied  was  designed  to  exactly 
replicate  the  motions  of  the  ESD  data  elements  for  installing  and  removing  an  object  secured 
with  four  3/8  inch  bolts  using  a  boxed  end  wrench.  The  ESD  elements  were  decomposed 
onto  their  MTM-GPD  components  to  ascertain  the  exact  composition  of  the  elements.  The 
task  was  then  engineered  to  replicate  those  elements.  Element  components  such  as  the  size 
and  number  of  threads  on  the  bolts,  the  number  of  threads  turned  by  hand,  the  number  of 
threads  turned  with  the  wrench,  and  the  amount  of  swing  on  the  wrench  were  made  to 
correspond  to  the  ESD  elements. 
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The  task  involved  positioning  a  5  x  5  x  1.5  inch  object  on  a  mounting  plate  and 
securing  it  with  four  3/8  inch  bolts,  using  a  boxed  end  wrench,  and  then  removing  it.  The 
bolts  were  installed  through  holes,  located  in  each  corner  of  the  objects,  into  threaded  holes  in 
the  mounting  plate.  The  variables  in  this  study  were  the  orientation  of  the  mounting  plate,  the 
weight  of  the  object  and  the  distance  between  an  access  opening,  through  which  the  object 
was  installed  and  removed,  and  the  mounting  plate.  (The  access  opening  was  19.5  x  19.5 
inches  and  did  not  restrict  access  to  the  mounting  plate,  other  than  distance  away.)  Each 
experimental  condition  was  performed  five  times  including  the  practice  trials.  The  subjects  in 
this  study  were  three  males  and  two  females  recruited  from  the  SRL  subject  pool. 

It  was  not  possible  to  draw  any  conclusions  about  the  effects  of  distance  and  object 
weight.  Shorter  and  weaker  subjects  reported  being  unable  to  perform  the  task  at  the  far 
distance  and/or  with  the  heavier  weight  object.  Therefore  the  task  was  modified  to  allow 
those  subjects  to  complete  it.  However,  it  was  the  opinion  of  the  experimenter  that  those 
subjects  could  have  performed  the  tasks  if  they  had  been  motivated  to  do  so. 

One  interesting  finding  was  obtained  in  this  study  through  the  experimenters 
observation  of  subjects  performing  the  task  using  the  heavy  weight  object.  When  the 
mounting  plate  was  vertical,  thus  requiring  the  subject  to  support  the  weight  with  one  hand, 
the  subject's  weight  quicken.  The  subjects  seemed  to  speed  up  their  performance  in  order  to 
avoid  becoming  overcome  by  fatigue. 

The  most  important  finding  in  this  experiment  was  the  close  correspondence  between 
the  times  obtained  in  this  study  and  the  times  obtained  from  the  ESD  database.  The  task 
condition  using  the  two  pound  object  at  the  close  distance  was  used  for  the  comparison 
because  that  condition  replicated  the  ESD  elements.  The  following  is  a  comparison  of  the 
time  study  results  and  ESD. 
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Table  8.  ESD  Analysis  for  Installation  and  Removal  of  a 
Component  Secured  with  4  Bolts 


DESCRIPTION 

CODE 

TMU 

occ 

TMU 

Install 

Get  and  position  component 

OOH-PO-OA 

120 

0100 

120 

Install  first  bolt 

OTF-SM-EB 

1060 

0100 

1060 

Install  additional  bolts 

OTF-SM-XB 

860 

0300 

2580 

ESD  ANALYSIS  IN  SEC.  =  135.36 

EXPERIMENTAL  DATA  IN  SEC.  =  135.70 


DESCRIPTION 

CODE 

TMU 

OCC 

TMU 

A.  Remove 

1 .  Remove  first  bolt 

OTF-SM-RB 

1000 

0100 

1000 

2.  Remove  additional  bolts 

OTF-SM-YB 

820 

0300 

2460 

3.  Lay  aside  component 

OMH-LA-OA 

50 

0100 

50 
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ESD  ANALYSIS  IN  SEC. 
EXPERIMENTAL  DATA  IN  SEC. 


126.36 

125.09 


Note:  Case  B  (easy)  difficulty  was  used  in  the  ESD  analyses  for  bolt  installation  and  removal 
due  to  the  use  of  a  boxed  end  wrench.  Experimental  data  results  are  means  of 
unedited  raw  data  from  the  first  five  subjects,  four  test  trials  and  one  practice  trial 
(N=25). 

The  next  two  experiments  were  designed  to  further  examine  the  validity  of  the  ESD 
database.  As  well  as  times  for  simple  maintenance  tasks,  the  ESD  database  also  incorporates 
a  system  of  determining  the  difficulty  of  a  task  and  predicting  the  increased  time  required  to 
accomplish  it.  These  experiments  were  designed  to  investigate  the  validity  of  the  ESD  system 
for  determining  task  difficulty  and  quantify  the  factors  which  cause  the  task  to  be  difficult. 

The  ESD  system  uses  five  levels  of  difficulty  ranging  from  "very  easy"  (level  1)  to 
"very  difficult"  (level  5).  The  ESD  difficulty  levels  are  based  on  three  variables  which  affect 
time;  weight,  distance,  and  control.  The  following  are  the  ESD  definitions  of  the  variables  for 
each  of  the  five  levels. 

Weight  Level  1  0  to  3  pounds 

Level  2  over  3  to  10  pounds 
Level  3  over  10  to  25  pounds 
Level  4  over  25  to  50  pounds 
Level  5  over  50  pounds 

Distance  Level  1  within  an  1 8  inch  radius 
Level  2  within  a  30  inch  radius 
Level  3  within  a  4  foot  radius 
Level  4  within  a  6  foot  radius 
Level  5  within  an  8  foot  radius 

Control  Level  1  Accomplishment  is  unobstructed  and  object  is  clearly  visible. 

Closeness  of  fit  (where  applicable)  is  loose  and  object  is  easy  to 
handle. 

Maximum  recoil  is  1  inch. 
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Level  2  Accomplishment  has  SOME  interference  and  object  is  visible,  or 
there  is  no  interference  and  object  is  PARTIALLY  visible. 


Closeness  of  fit  (where  applicable)  is  loose  and  object  is  difficult  to 
handle. 

Maximum  recoil  is  1  inch. 

Level  3  Accomplishment  contains  interference  and  object  is  PARTIALLY 
visible. 

Closeness  of  fit  (where  applicable)  is  close. 

Maximum  recoil  is  5  inches. 

Level  4  Accomplishment  contains  interference  and  object  is  NOT  visible. 
Closeness  of  fit  (where  applicable)  is  exact. 

Recoil  over  5  inches. 

Level  5  Accomplishment  is  OBSTRUCTED  and  object  is  NOT  visible. 

Closeness  of  fit  (where  applicable)  is  exact  with  multiple  and/or 
non-symmetrical,  difficult  positions. 

It  can  be  seen  that  ESD  difficulty  levels  for  the  factors  weight  and  distance  can  be 
easily  determined.  However,  the  level  of  control  requires  a  subjective  determination  based  on 
the  amount  of  interference,  visibility,  and  closeness  of  fit  between  mating  parts.  Furthermore, 
the  ESD  system  does  not  assign  equal  importance  to  each  of  the  three  variables.  The  relative 
contribution  to  difficulty  assigned  to  these  variables  is  5%  for  weight,  10%  for  distance,  and 
85%  for  control.  Since,  the  difficulty  levels  for  weight  and  distance  can  be  objectively 
obtained  and  contribute  relatively  little  to  task  difficulty,  these  studies  were  designed  to 
validate  and  attempt  to  quantify  the  subjective  factor  of  control. 
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The  task  used  in  these  studies  involved  the  disassembly  and  reassemble  of  a  flange  type 
pipe  fitting.  The  simulated  flange  fitting  was  held  together  with  four  1/4  inch  bolts  and  self- 
locking  nuts.  A  flexible  rubber  hose  was  attached  to  an  end  of  the  fitting,  requiring  the  subject 
to  position  and  align  the  two  pieces  of  the  fitting  and  hold  them  in  place  with  one  hand  while 
the  first  bolt  was  inserted.  The  fitting  was  mounted  horizontally  to  the  subject  with  the  bolt 
being  inserted  from  the  bottom  and  the  nut  on  top. 


The  variables  used  in  these  studies  were;  tool  type,  tool  interference,  and  access 
opening  size.  The  task  required  the  use  of  two  tools,  one  on  the  nut  and  one  on  the  bolt  head. 
The  2  tool  combinations  used  were  as  follows: 


Tool  on  nut  (topi 
Ratchet  wrench  with  socket 
Boxed  end  wrench 
Boxed  end  wrench 
Open  end  wrench 
Open  end  wrench 


Tool  on  bolt  head  ('bottom') 
Boxed  end  wrench 
Boxed  end  wrench 
Open  end  wrench 
Open  end  wrench 
Open  end  wrench 


Tool  interference  was  accomplished  by  placing  a  vertical  wall  type  barrier  adjacent  to  one  of 
the  bolts  at  a  distance  of  two  inches.  Two  access  opening  sizes  were  used  in  the  studies,  a 
19.5  x  19.5  inch  opening  and  an  8  x  5  inch  opening.  The  large  opening  represents  the  size 
necessary  to  accommodate  a  95  percentile  male  working  with  both  hands,  through  an  opening 
up  to  the  shoulders.  This  opening  caused  no  physical  or  visual  interference.  The  small 
opening  represents  the  minimum  size  allowable  by  MIL-STD-1472D  for  two-handed  work. 


The  first  study  employed  48  subjects  divided  into  eight  groups  of  six  subjects  each. 
Each  subject  performed  three  trials  on  two  of  the  experimental  conditions,  for  a  total  of  six 
disassembly  and  reassembly  trials.  Subjects  were  also  given  the  opportunity  to  practice  the 
least  and  most  restrictive  conditions,  up  to  a  total  of  three  trials.  The  order  in  which  the  task 
conditions  were  performed  was  counterbalanced  within  each  group.  The  task  conditions 
performed  by  each  group  were  as  follows. 
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WRENCH 


INTERFERENCE 


GROUP 


Ratchet/Boxend 

Present 

1 

Ratchet/Boxend 

Absent 

1 

Boxend/Boxend 

Present 

Boxend/Boxend 

Absent 

Open/Boxend 

Present 

Open/Boxend 

Absent 

Boxend/Open 

Present 

7 

Boxend/Open 

Absent 

7 

Open/Open 

Present 

8 

Open/Open 

Absent 

8 

Groups  7  and  8  were  not  included  in  the  original  experimental  design.  They  were  added  after 
the  study  was  in  progress. 

This  experimental  design  was  developed  as  an  attempt  to  control  for  the  effects  of 
practice  and  transfer  of  training  between  experimental  condition.  Figure  6  shows  the  mean 
total  task  times  for  each  trial  across  experimental  condition.  The  figure  shows  that  some 
learning  did  occur,  however,  the  effect  was  minimal  with  only  a  5.6%  increase  from  first  to 
third  trial. 
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1  4  0 


T  ria  1  1  T  ria  I  2  T  ria  I  3 


Figure  6.  Mean  Task  Times  for  Each  Trial 

Across  All  Experimental  Conditions 

In  the  first  study  only  the  19.5  x  19.5  inch  access  opening  was  used.  The  second  study 
was  a  replication  of  the  first  using  the  8x5  inch  access  opening.  The  second  study  employed 
48  new  subjects  who  did  not  participate  in  the  first  study. 

According  to  the  ESD  definitions  for  control,  Level  1  contr  olves  no  interference 
and  complete  visibility.  These  conditions  correspond  to  the  Time  study  condition  using  the 
19.5  x  19.5  inch  access  opening  with  no  interference  barrier  present.  It  should  be  noted  here 
that  the  use  of  two  boxed  end,  open  end,  or  combination  wrenches  constitutes  Level  2  control 
in  the  ESD  database.  This  is  not  obvious  from  the  definitions,  it  was  discovered  by  UDRI 
upon  examination  of  the  ESD  database,  and  confirmed  by  the  Navy's  representative.  The 
reason  for  this  is  the  need  to  reposition  one  of  the  wrenches  on  every  turn,  requiring  more 
control  than  a  ratchet  wrench  or  speed  hand  type  tool.  Therefore,  the  only  experimental 
condition  in  our  time  study  which  conforms  to  the  definition  of  Level  1  difficulty  is  that  using 
the  Ratchet  wrench  with  socket  and  boxed  end  wrench  (RAT-BOX).  The  mean  time  for 
installing  and  removing  a  bolt  and  nut  with  the  RAT-BOX  tools  through  the  19.5  x  19.5  inch 
opening  with  no  interference  barrier,  is  presented  in  Figure  7.  Also,  presented  in  the  figure  is 
the  corresponding  ESD  element  Times. 

All  ESD  elements  for  installing  and  removing  bolts,  contain  additional  time  for 
installing/removing  washers.  To  keep  the  content  of  the  ESD  element  consistent  with  the 
study,  the  MTM-GPD  element  times  used  to  add  the  time  for  washers  in  the  construction  of 
the  ESD  elements  were  subtracted  from  the  ESD  element  time.  Also,  note  that  the  time  study 
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results  shown  are  for  Bolt  #3.  Since  Bolt  #3  was  where  the  interference  barrier  was  present, 
all  results  presented  will  be  those  obtained  on  Bolt  #3 . 
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RAT-BOX  Wrenches 
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BSD  etor rams  OTF-8M-4A  (Install)  and 
OTF-BM-flA  ^remove),  minu«  Ihe  f  me  for 
installing  and  removing  washer. 


Figure  7.  Laboratory  Time  Study  Data  vs. 
ESD  Level  1  Data 


It  can  be  seen  from  the  figure  that  the  time  study  results  conform  very  closely  to  the 
time  predicted  by  the  ESD  element.  Recall  that  the  ESD  definition  of  control  stated  that  some 
interference  constituted  Level  2  control  if  the  object  is  clearly  visible.  That  condition 
corresponds  to  using  the  RAT-BOX  tools  through  the  large  opening  with  the  interference 
barrier  in  place.  Figure  8  shows  the  results  of  that  condition. 

The  ESD  definitions  of  control  also  stated  that  impaired  visibility  of  the  object  also 
constituted  Level  2  control.  That  condition  was  simulated  by  the  8x5  inch  access  opening. 
Figure  9  shows  the  mean  times  for  installing  and  removing  a  bolt  and  nut  with  the 
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RAT-BOX  tools  with  no  interference  barrier.  Again,  the  ESD  data  compares  very  closely  to 
the  time  study  data. 


e© 
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Install 

Remove 

ESD  Level  2 
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FIAT-BOX  with  INT 
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OTF-EIM-SKS  (remove),  minus  the  time  far 
ii  ii  flfa  ly  end  removing  washer. 


Figure  8.  The  Effect  of  Interference  on 

Laboratory  Time  Study  Data  vs. 
ESD  Level  2  Data 
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figure  9.  The  Effects  of  Interference  and 
Restricted  Access  on  Laboratory 
Time  Study  Data  vs.  ESD  Level  2  Data 

As  mentioned  earlier  the  use  of  two  boxed,  open,  or  combination  wrenches  constitutes 
Level  2  control.  ESD  does  not  differentiate  between  Boxed  end  wrenches,  open  end 
wrenches,  and  combination  wrenches.  The  reason  for  this  is  that  the  MTM-GPD  data  upon 
which  ESD  is  built  do  not  differentiate  between  them.  Therefore,  the  time  study  results 
presented  for  these  tools  are  the  mean  times  for  all  the  tools  combinations  which  used  two 
boxed  end  wrenches,  two  open  end  wrenches,  and  one  boxed  end  and  one  open  end  wrench; 
and  will  be  referred  to  as  combinations  wrenches  (COMB).  Figure  10  shows  the  mean  times 
for  installing  and  removing  a  bolt  and  nut  with  two  combination  wrenches  through  the  large 
opening  with  no  interference  barrier.  It  can  be  seen  from  the  figure  that  all  of  the  conditions 
which  correspond  to  Level  2  control  compare  very  favorably  with  the  ESD  Level  2  data 
element  times. 
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Figure  10.  The  Effects  of  Interference, 

Restricted  Access,  and  Wrench 
Type  on  Laboratory  Time  Study 
Data  vs.  ESD  Level  2  Data 


Thus  far,  the  results  of  the  time  studies  have  provided  strong  evidence  that  the  ESD 
data  valid  for  predicting  times  for  task  which  correspond  to  their  definition  of  Level  1  and 
Level  2  difficulty.  Furthermore,  the  results  have  allowed  the  assignment  of  object,  measurable 
task  condition  to  the  ESD  subject  definitions  of  control.  It  was  found  that  an  interference 
located  at  a  distance  less  than  the  length  of  the  wrench  used  and  restricts  movement  of  the 
wrench  constitutes  Level  2  control.  Also,  working  through  an  opening  which  restricts  vision 
constitutes  Level  2  control.  These  are  conditions  which  can  be  identified  by  the  CREW 
CHIEF  model  for  input  into  the  TTE. 

The  ESD  definition  of  Level  3  control  states  that,  accomplishment  contains 
interference  and  the  object  is  partially  visible.  This  corresponds  to  the  experimental  condition 
which  uses  RAT-BOX  tool  through  the  small  access  opening  with  the  interference  barrier 
present.  Figure  1 1  presents  the  mean  installation  and  removal  times  for  that  condition  along 
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with  the  ESD  element  times  for  Level  3  control.  Inspection  of  the  figure  shows  very  close 
correspondence  between  the  Time  study  data  and  the  ESD  Level  3  element  times. 
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Figure  11.  The  Combined  Effect  of  Interference 
and  Restricted  Access  on  Laboratory 
Time  Study  Data  vs.  ESD  Level  3  Data 


It  was  shown  from  the  time  study  results  that  when  interference  was  introduced  into  a 
Level  1  task  condition,  the  time  increased  to  approximately  that  of  Level  2.  The  same  was 
true  when  vision  was  restricted.  What  if  those  variables  were  introduced  into  a  Level  2  task 
such  as  the  installation  and  removal  of  a  bolt  and  nut  with  two  combination  wrenches? 
Figures  12  and  13  show  that  the  time  increased  to  approximately  that  of  Level  3. 
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Figure  12.  The  Combined  Effects  of  Interference 
and  Restricted  Access,  and  Interference 
and  Tool  Type  on  Laboratory  Time  Study 
Data  vs.  ESD  Level  3  Data 
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Figure  13.  The  Combined  Effects  of  Interference 
and  Restricted  Access,  Tool  Type  and 
Interference,  and  Tool  Type  and  Restricted 
Access  on  Laboratory  Time  Study  Data  vs. 
ESD  Level  3  Data 


To  carry  this  logic  one  step  further,  if  the  task  condition  using  two  combination 
wrenches  contained  both  interference  and  restricted  access  it  would  correspond  to  ESD  level 
4  difficulty.  Figure  14  shows  that  this  is  indeed  the  case. 
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ESQ  elements  were  calulated  using  the 
ESD  time-difficulty  ratio  formula. 

Figure  14.  The  Combined  Effects  of  Tool 
Type,  Interference,  and  Restricts 
Access  on  Laboratory  Time  Study 
Data  vs.  ESD  Level  4  Data 


Validation  of  TTE  Time-To-Repair  Estimates.  UDRI  has  developed  a  plan  to 
validate  the  task  time  computations  produced  by  the  TTE  against  Actual  flightline 
maintenance.  With  the  assistance  of  the  Air  Force,  UDRI  will  schedule  and  obtain  prior 
approval  for  visits  to  maintenance  facilities  in  the  vicinity  of  WPAFB  to  videotape 
maintenance  tasks.  The  UDRI  personnel  who  will  be  involved  with  this  task  have  active 
security  clearances,  which  is  necessary  for  access  to  the  flightline.  The  target  facilities  will 
include  the  Air  National  Guard  at  Springfield  Municipal  Airport,  the  906th  Fighter  Group, 
and  the  4950th  Test  Wing,  both  at  WPAFB.  To  minimize  the  impact  to  and  disruption  of 
flightline  activities,  the  task  selected  validation  will  be  chosen  from  scheduled  maintenance 
activities.  This  will  also  eliminate  any  additional  aircraft  downtime  and  maintenance  man¬ 
hours,  facilitate  receiving  Air  Force  approval,  and  (we  hope)  provide  better  cooperation  from 
the  technicians. 
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Once  the  tasks  are  videotaped,  the  tapes  will  be  brought  back  to  the  Physical 
Ergonomics  Laboratory  for  review.  The  times  will  be  extracted  using  a  stopwatch  with  any 
inappropriate  delay  times  being  removed  from  the  data.  These  will  include  values  that  are  plus 
or  minus  three  standard  deviations  from  the  mean  or  times  on  tasks  where  interruptions  occur. 
The  difficulty  of  task  elements  will  be  determined  from  CREW  CHIEF  difficulty  definitions. 
Once  difficulty  is  established,  the  time-difficulty  models  will  be  applied  to  enable  us  to 
compare  the  actual  flightline  task  times  to  the  simulated  laboratory  task  times  for  validation. 

2.2  Develop  Space  Maintenance  Model 

In  accordance  with  P00020  of  this  contract,  this  portion  of  the  effort  was  deleted. 

2.3  Rehost  CREW  CHIEF  on  other  CAD  Systems 

The  CREW  CHIEF  program  has  been  rehosted  on  several  additional  CAD  systems. 
CREW  CHIEF  interfaces  are  now  available  on  four  major  CAD  systems.  These  CAD  systems 
run  under  eight  different  operating  systems.  There  are  two  major  factors  for  choosing  the 
CAD  systems  and  operating  systems  used  for  CREW  CHIEF  interfaces.  The  first  factor  is  the 
availability  of  the  hosts  in  the  Computer  Aided  Workplace  and  Design  Facility.  The  second 
factor  is  the  survey  of  CREW  CHIEF  users.  Survey  results  showed  that  95%  of  CREW 
CHIEF  users  either  had,  or  planned  to  acquire,  at  least  one  CREW  CHIEF  host  system. 

CREW  CHIEF  Hosts 

CAD  AM 

CREW  CHIEF  is  interfaced  to  Version  21  of  the  CAD  AM  CAD  system 
running  under  the  IBM  MVS  and  VM  operating  systems.  An  interface  to  Pro 
CAD  AM  running  under  the  IBM  AIX  operating  system  is  in  progress. 

CATIA 

CREW  CHIEF  was  interfaced  to  Version  3  of  the  CATIA  CAD  system 
running  under  the  IBM  MVS  and  AIX  operating  systems. 
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I-DEAS 


CREW  CHIEF  was  interfaced  to  level  V  of  the  I-DEAS  CAD  system  running 
under  the  Silicon  Graphics  IRIX  operating  system.  CREW  CHIEF  was  also  interfaced 
to  level  VI  of  the  I-DEAS  CAD  system  running  under  the  Sun  SUNOS  operating 
system. 

Unigraphics 

CREW  CHIEF  is  currently  being  interfaced  to  Version  9.0  of  the  Unigraphics 
CAD  system  running  under  the  Sun  SUNOS  operating  system. 

2.3.1  Rehost  CREW  CHIEF  on  Other  IBM  CAD  Systems 

Under  paragraph  3. 1.3.1  of  the  SOW,  UDRI  was  required  to  rehost  CREW  CHIEF  on 
other  IBM  CAD  systems.  To  satisfy  these  requirements,  UDRI  developed  and  released 
Versions  2  and  3  of  CREW  CHIEF  with  interfaces  to  CAD  AM  21  (under  both  VM  and  MVS 
operating  systems)  and  CATIA  (under  VM,  MVS,  and  the  AIX  operating  systems).  UDRI 
also  made  many  of  the  changes  to  the  CAD  AM  21  interface  needed  to  make  that  interface 
compatible  with  ProCadam  (under  the  AIX  operating  system),  but  due  to  the  low  number  of 
requests  for  this  interface  and  time  constraints,  this  interface  was  delayed  for  further 
consideration. 

The  CAD  AM  21  interface  was  developed  under  the  MVS  operating  system.  UDRI 
developed  the  CAD  AM  21  interface  using  the  Common  User  Interface  (CUT)  in  conjunction 
with  CAD  AM's  Interactive  User  Exchange  (IUE)  module  developed  for  CAD  AM  software 
applications.  Under  CAD  AM  IUE,  UDRI  developed  icons  which  can  be  selected  by  the  user 
to  invoke  CREW  CHIEF  function  modules.  For  the  MVS  version  of  CREW  CHIEF,  UDRI 
separated  each  function  into  a  separate  module  in  order  to  save  space  in  the  mainframe's  core 
memory.  Each  function  module  consisted  of  a  set  of  FORTRAN  routines  for  the  core 
function  software,  a  set  of  routines  for  the  Common  User  Interface  (CUT)  software,  and  the 
software  developed  to  drive  the  interface  at  the  CAD  level  (in  this  case,  the  routines  which 
used  CAD  AM  IUE  routines  for  graphical  input  and  output,  menus,  prompts,  help  tables,  and 
icons).  Since  the  core  memory  on  the  MVS  system  was  small  in  comparison  to  what  was 
needed  for  each  function,  every  function  had  to  have  its  own  overlay  structure  to  allow  the 
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system  supervisor  to  load  the  appropriate  chunks  of  code  at  function  run  time  (i.e.,  when  the 
user  picks  the  icon  representing  a  specific  function).  All  of  the  CAD  AM  21  interface  code 
was  written  in  FORTRAN  for  compatibility  with  the  CAD  AM  IUE  FORTRAN  routines. 

For  the  Version  II  interface,  code  and  databases  were  updated  mostly  for  ease  of  use 
considerations  and  for  ridding  the  code  of  minor  bugs.  For  example,  the  window  settings 
were  saved  when  the  user  entered  a  CREW  CHIEF  function  (via  an  icon  selection).  This 
modification  allowed  the  interface  to  present  the  user  with  a  window  which  had  all  the 
geometry  and  text  centered  and  scaled  properly  regardless  of  whether  the  user  is  making  a 
menu  selection,  geometry  pick,  or  an  alphanumeric  key-in.  Previously  CAD  AM  had  not 
allowed  us  access  to  the  routines  which  read  and  set  the  window  settings.  Also,  the  number  of 
icons  available  for  selection  along  with  the  menu  text  increased  to  help  the  user  visually 
determine  what  is  actually  defined  by  each  menu  pick.  The  help  tables  were  also  updated  to 
accurately  describe  in  detail  what  each  menu,  key-in,  or  geometry  pick  was  actually  defining. 
Finally,  the  wording  of  the  prompts  were  all  updated  to  make  the  interface  easier  to  navigate 
through  in  an  intelligible  way.  These  changes  were  then  tested  fiilly  one  function  at  a  time. 

For  the  Version  3  interface,  the  Link  Table  and  Grasp  function  interfaces  were  added 
using  the  Common  User  Interface  (CUI)  to  parallel  methods  used  for  developing  the  Version 
II  interface.  These  two  function  interfaces  were  integrated  into  the  overall  interface  of  CREW 
CHIEF  and  fully  tested  and  validated.  Note  that  during  this  time  period,  all  of  the  CUI 
prompts  were  standardized  and  updated  which  forced  full  testing  and  validation  of  the 
previous  16  function  interfaces  already  developed  for  CADAM  21  as  well. 

Once  these  interfaces  were  developed,  UDRI  cut  and  tested  the  distribution  tapes  and 
validated  the  installation  directions.  Then,  the  interface  was  ported  over  to  the  VM  operation 
system  by  recompiling  all  the  source  code  and  writing  the  necessary  procedures  on  the  VM 
system  to  generate  the  executable  modules  and  enable  validation  on  the  VM  system.  Then  the 
VM  distribution  tapes  were  cut  and  master  copies  retained  for  subsequent  tape  copies  as 
orders  came  in  for  this  interface. 

For  the  CATIA  interface,  UDRI  used  an  interface  developed  by  Boeing  as  a  starting 
point  in  order  to  save  time.  Boeing  started  the  interface  by  using  the  Function  Structure 
Definition  (FSD)  language  provided  by  CATIA  to  develop  CATIA  type  functions.  The  FSD 
language  is  used  to  present  the  user  with  CATIA  type  menus  and  prompts.  The  menus  are 
selected  to  invoke  more  menus  or  task  subroutines  (written  in  FORTRAN).  UDRI  (and 
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Boeing)  developed  several  types  of  task  subroutines  for  the  CREW  CHIEF  interface  to 
CATIA.  Some  of  the  task  subroutines  allow  geometry  selection  (using  the  CATIA  Data  Input 
Manager  (DIM)  of  the  CATIA  Graphics  Interactive  Interface  (GII)  module).  Other  task 
subroutines  provide  CATIA  type  panels  (2-D  windows  with  text)  using  the  CATIA  Graphics 
Interface  (CATCGI)  portion  of  CATIA's  GII  module.  These  panels  were  developed  to  allow 
the  user  to  input  data  associated  with  the  menu  selected.  UDRI  stored  all  the  data  in  the 
CREW  CHIEF  function  control  commons  for  use  by  the  core  when  the  final  task  for  the 
selected  function  is  invoked  via  menu  selection.  The  final  task  is  used  to  execute  the  selected 
function  analysis  and  output  the  appropriate  information  to  the  user  through  the  use  of  the 
CATIA  supplied  CATCGI  portion  of  the  GII  module.  In  order  to  obtain  geometric 
information  from  the  CATIA  drawing  database,  UDRI  developed  (and  enhanced  that  which 
was  already  available  from  the  Boeing  partial  interface  to  CATIA)  the  CREW  CHIEF 
geometry  input  interface  to  CATIA.  To  accomplish  this,  UDRI  used  the  CATIA  FORTRAN 
routines  provided  by  the  Geometry  Interface  (CATGEO)  module  to  access  the  CATIA  data 
structures. 

UDRI  continued  building  on  the  partial  interface  developed  by  Boeing  to  produce  a 
complete  CATIA  interface  for  Version  II  of  CREW  CHIEF.  UDRI  finished  the  interface  by 
updating  the  FSD  code,  writing  new  FSD  code,  updating  task  subroutines,  and  developing 
new  task  subroutines  for  almost  all  of  the  CREW  CHIEF  functions.  UDRI  developed  the 
entire  Reposition  function  and  redesigned  most  of  the  materials  handling  function  interfaces  to 
CATIA. 

Once  all  the  code  for  the  tasks  and  menus  was  written,  UDRI  used  the  CATDCG 
utility  provided  by  CATIA  to  compile  the  FSD  code.  Then  UDRI  used  the  LKFCAPI 
procedure  to  link  the  code  with  the  CATIA  geometry  interface  routines.  Finally,  UDRI 
integrated  the  executable  code  into  CATIA  using  the  CATIA  Function  Integration  (CATFID) 
utility  provided  by  CATIA.  This  final  step  allows  CREW  CHIEF  to  be  selected  as  a  menu 
item  just  like  the  rest  of  the  CATIA  functions. 

For  the  Version  3  CREW  CHIEF  interface  to  CATIA,  UDRI  developed  all  the  FSD 
code  needed  for  the  Link  Table  and  Grasp  function  interfaces.  This  code  was  developed  more 
modular  than  the  FSD  code  generated  for  Version  II.  UDRI  also  developed  all  the 
FORTRAN  routines  needed  for  the  task  processing  dictated  by  the  menu  trees  developed  in 
the  FSD  code  for  these  function  interfaces.  UDRI  also  implemented  geometry  interface 
updates  provided  by  Boeing  periodically  to  allow  for  more  CATIA  elements  to  be  processed 
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for  obstacle  avoidance  considerations.  These  updates  allowed  solids,  dittos,  and  details  to  be 
processed  as  well  as  the  drawing  elements  allowed  for  the  Version  II  interface  of  CATIA. 

Due  to  size  constraints  on  the  MVS  development  system,  UDRI  performed  most  of 
the  CATIA  interface  development  on  the  AIX  operating  system.  All  of  the  validation  on  the 
MVS  operating  system  was  performed  by  Boeing.  The  source  code  generated  on  the  AIX 
system  was  loaded  onto  both  the  MVS  and  VM  operating  systems  for  compilation  and 
linkage.  Distribution  tapes  were  cut  for  both  of  these  systems.  Since  the  AIX  version  of  the 
CREW  CHIEF  interface  to  CATIA  was  relatively  small  once  compressed,  and  since  most 
IBM  RS6000  workstations  come  with  a  3.5  inch  floppy  drive,  the  distribution  of  the  CREW 
CHIEF  CATIA  interface  for  the  AIX  system  was  performed  using  the  3.5  inch  floppy  disks. 

2.3.2  Rehost  CREW  CHIEF  on  VAX  Based  CAD  Systems 

The  SOW  required  the  reprogramming  of  the  CREW  CHIEF  model  to  operate  on  two 
CAD  systems  based  on  DEC  VAX  systems.  Contract  modification  P00020,  deleted  this 
requirement  from  the  contract. 

2.3.3  Rehost  on  Other  Platforms 


The  SOW  requires  that  the  CREW  CHIEF  model  be  rehosted  on  additional  CAD 
systems.  These  CAD  systems  must  be  locally  available  and  in  use  by  major  aerospace 
contractors.  CREW  CHIEF  has  been  rehosted  on  I-DEAS  Level  V,  I-DEAS  Level  VI  and 
Unigraphics  Version  9  CAD  systems.  These  CAD  systems  reside  on  Silicon  Graphics  Iris 
workstations  and  Sun  SPARCstations. 

Silicon  Graphics 

The  CREW  CHIEF  model  has  been  rehosted  on  two  CAD  systems  on  a  Silicon 
Graphics  workstation.  The  CAD  systems  available  to  us  on  the  Silicon  Graphics  platform  are 
I-DEAS  Level  V  and  I-DEAS  Level  VI.  The  I-DEAS  Level  V  rehosting  took  place  on  a 
Personal  Iris  system.  The  I-DEAS  Level  VI  rehosting  took  place  on  an  Iris  4-D  system.  Both 
I-DEAS  interfaces  use  the  CUI  for  the  interface.  These  interfaces  use  the  Director/Ob  server 
facility  of  the  I-DEAS  CAD  system.  Another  critical  part  of  these  interfaces  is  the  use  of  I- 
DEAS  Universal  files. 
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Sun  SPARCstation 


One  of  the  two  CAD  systems  on  which  the  CREW  CHIEF  model  was  rehosted  was  I- 
DEAS  VI  on  a  Sun  SPARCstation  workstation.  The  I-DEAS  rehosting  uses  the  CUI  for  the 
interface.  This  interface  uses  the  Director/Observer  facility  of  the  I-DEAS  CAD  system. 
Another  critical  part  of  this  interface  is  the  use  of  I-DEAS  Universal  files. 

The  other  CAD  system  available  on  the  Sun  SPARCstation  is  Unigraphics  Version  9. 
This  rehosting  uses  the  CUI  for  the  interface.  This  interface  uses  the  Unigraphics  User 
Function  facility. 


2.4  Maintain  CREW  CHIEF  Software  and  Documentation 

Paragraph  3.1.4  required  the  CREW  CHIEF  software  and  documentation  be 
maintained. 

The  official  CREW  CHIEF  software  is  maintained  on  a  SPARCStation,  SUNOS.  All 
notices  of  changes  and  updates  are  given  to  the  software  manager.  The  software  manager 
updates  the  official  software  and  then  notifies  all  programmers  of  the  updates.  The  software 
is  then  updated  on  each  hardware  platform  by  the  person  responsible  for  that  specific 
platform. 

Updates  to  CAD  dependent  software  is  handled  a  little  differently.  The  CATIA 
interface  was  developed  by  Boeing  and  updates  or  modifications  to  this  interface  are  sent  to 
us  from  Boeing.  We  then  update  our  version  of  the  CATIA  interface  software.  A  CREW 
CHIEF/CATIA  user's  guide  is  available. 

I-DEAS  interface  software  is  updated  and  tested  on  a  SPARCStation.  Once  updates, 
modifications,  or  enhances  have  been  fully  tested,  all  programmers  are  informed  of  the 
changes.  The  ProCADAM  interface  is  compatible  with  the  CAD  AM  21  interface  and 
therefore  uses  the  same  user's  guide  as  the  CREW  CHIEF/C  AD  AM  21  version. 

The  ProCADAM  interface  software  is  updated  on  a  RS6000  system.  Again,  once 
updates,  modifications,  or  enhancements  have  been  fully  tested,  all  programmers  are  informed 
of  the  changes.  The  ProCADAM  interface  is  compatible  with  the  CAD  AM  21  interface  and 
therefore  uses  the  same  user's  guide  as  the  CREW  CHIEF/CAD  AM  21  version. 
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CAD  AM  21  interface  software  is  hosted  on  an  MVS  system.  At  present  we  do  not 
have  convenient  access  to  a  MVS  system  for  updates.  Previously  we  updated  the  interface 
software  in  the  same  manner  as  the  previously  mentioned  CAD  system  interfaces  to  CREW 
CHEF.  A  CREW  CHIEF  CADAM  21  user's  guide  is  available. 

Unigraphics  interface  software  is  hosted  on  the  SPARCStation.  This  interface  is  still 
under  development.  At  present  there  is  no  user's  guide. 

Also  available  is  a  CAD  System  Independent  version  of  CREW  CHIEF.  This  software 
is  basically  the  official  core  software  and  is  maintained  on  the  SPARCStation.  A  CAD  System 
Independent  guide  is  available. 

All  user's  guides  are  kept  up-to-date.  As  enhancements  are  made  to  CREW  CHIEF, 
the  user's  guides  are  updated.  If  new  functions  have  been  incorporated,  the  users'  guides  have 
been  updated  accordingly. 
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SECTION  3  -  ENHANCE  AND  UPDATE  COMBIMAN 


The  contract  SOW  required  three  major  areas  of  enhancement  for  COMBIMAN. 
First,  UDRI  was  tasked  to  develop  a  host-independent  version  of  COMBIMAN.  As  with 
CREW  CHIEF,  UDRI  was  tasked  to  rehost  COMBIMAN  on  other  CAD  systems.  Finally, 
UDRI  was  tasked  to  develop  three  seat  models  for  use  with  COMBIMAN  analyses.  All 
relevant  software  and  documentation  had  to  be  maintained  too. 

3.1  Develop  Host-Independent  COMBIMAN 

COMBIMAN  Version  8 


The  COMputerized  Biomechanical  huMAN  model  (COMBIMAN)  is  an  interactive 
computer  graphics  engineering  tool,  that  represents  an  operator  in  a  crew  station.  Version  8 
of  COMBIMAN  was  a  standalone  system.  The  functions  of  COMBIMAN  Version  8  can  be 
classified  as  human  model  simulation  and  geometry  manipulation.  The  geometry  manipulation 
includes  many  typical  CAD  system  functions.  These  functions  include  crew  station 
manipulation,  view  manipulation  and  hard  copy  generation. 

COMBIMAN  Version  8  runs  on  an  IBM  system/370,  303x,  43xx,  or  equivalent 
computer.  COMBIMAN  requires  an  IBM  2250-III  or  equivalent  display  unit.  The 
COMBIMAN  Version  8  software  has  calls  to  the  obsolete  IBM  Graphics  Subroutine  Package 
deeply  embedded  in  the  code. 

COMBIMAN  Version  9 


Version  9  of  COMBIMAN  was  structured  into  two  distinct  modules.  This  redesign 
has  a  graphics  input  and  output  module  that  allows  a  host  CAD  system,  or  other  graphics 
package,  to  perform  all  graphics  operations.  The  other  module,  in  Version  9  COMBIMAN, 
performs  the  human  model  simulation.  The  new  structure  of  COMBIMAN  is  the  same  as  the 
CREW  CHIEF  program.  COMBIMAN  functions  are  shown  in  Figure  15.  The  following 
paragraphs  describe  the  human  model  functions  of  COMBIMAN  Version  9. 


81 


Generation  Functions 


Initialization 
Regeneration 
Head  Orientation 

Link  Table 
Reposition 

Activity  Analysis  Functions 

Reach 
Strength 
Reach  Envelope 
Visibility 
Interference 

Status  Functions 

Configuration 

Figure  15.  COMBIMAN  Functions 
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Initialization  Function 


The  Initialization  function  generates  the  COMBIMAN  human  model.  The 
COMBIMAN  program  includes  six  built-in  populations.  The  program  has  five 
methods  to  generate  body  size.  COMBIMAN  provides  seven  clothing  types. 

Regeneration  Function 

The  Regeneration  function  regenerates  the  COMBIMAN  model  display.  This 
function  uses  the  enfleshment  from  the  last  successful  positioning  function. 
Positioning  occurs  during  the  Generation  functions  or  during  a  Reach  analysis. 

Head  Orientation  Function 


The  Head  Orientation  function  moves  the  COMBIMAN  model's  head  toward 
some  specified  target  point.  The  COMBIMAN  model  turns  its  head  within  the 
allowable  ^Mity  constraints.  If  the  target  point  already  lies  within  the  model's  view, 
the  COMbiiviAN  model  does  not  turn  its  head. 

Link  Table  Function 


The  Link  Table  function  allows  changes  to  be  made  to  the  angles  for  selected 
links  within  the  COMBIMAN  model's  link  system.  This  function  displays  angles  for 
16  of  the  36  links  in  COMBIMAN's  link  system.  The  user  can  enter  phi,  theta  and  psi 
values  corresponding  to  the  Euler  angles  for  the  selected  links. 

Reposition  Function 

The  Reposition  function  is  designed  to  augment  the  COMBIMAN  positioning 
functions.  This  function  allows  the  movement  of  peripheral  body  sections.  Reposition 
allows  movement  of  up  to  12  body  sections.  Mobility  constraints  will  still  be  enforced. 
Interference  is  not  checked. 
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Reach  Function 


The  Reach  function  allows  evaluation  of  the  aircrew  member's  capability  to 
reach  controls.  Controls  in  this  context  are  handles,  rudder  pedals  and  switches.  A 
successful  reach  depends  on  clothing  type,  body  mobility,  control  type  and  control 
location.  Mobility  limits  and  clothing  type  selection  cause  the  COMBEMAN  model  to 
reach  toward  the  designated  location  with  realistic  joint  mobility. 

Strength  Function 

The  Strength  function  allows  evaluation  of  the  aircrew  member's  capability  to 
reach  and  operate  controls.  Controls  in  this  context  are  handles,  rudder  pedals, 
switches  and  ejection  handles.  A  successful  reach  depends  on  clothing  type,  body 
mobility,  control  type  and  control  location.  Mobility  limits  and  clothing  type  selection 
cause  the  COMBIMAN  model  to  reach  toward  the  designated  location  with  realistic 
joint  mobility.  Strength  capabilities  are  predicated  on  the  assumption  that  force  cannot 
be  applied  unless  the  control  can  be  reached. 

Reach  Envelope  Function 

The  Reach  Envelope  function  determines  if  a  control  panel  lies  inside, 
intersects  with,  or  lies  outside  the  crew  member's  maximum  arm-reach  envelope.  This 
evaluation  is  performed  as  a  function  of  body  size,  clothing  type,  restraint  type  and 
control  type.  This  function  produces  a  reach  envelope  in  3-D  space  and  then 
computes  the  intersection  of  that  reach  envelope  with  a  user  selected  surface  in  the 
crew  station. 

Visibility  Function 

The  Visibility  function  generates  and  plots  a  map  of  the  angular  line-of-sight  to 
objects  in  a  crew  station.  MIL-STD-850  (Aircrew  Station  Vision  Requirements  for 
Military  Aircraft)  requires  visual  angle  maps  be  made  of  crew  stations.  MIL-STD-850 
allows  two  formats.  AitofFs  and  Rectilinear  projections.  Both  projections  are 
available  in  COMBIMAN. 
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Interference  Analysis  Function 


The  Interference  Analysis  function  checks  for  interference  between  the 
COMBEMAN  model  and  drawing  elements.  Interference  is  displayed  on  the  screen. 
Arrows  indicate  the  points  of  interference. 

Configuration  Function 

The  Configuration  function  displays  the  parameters  used  to  generate  the 
human  model.  This  function  lists  the  anthropometric  population,  clothing  type  and 
seat  reference  point.  All  other  definitions  are  included  in  the  display. 

A  significant  advantage  of  the  new  software  structure  for  COMBIMAN,  is  that  it  can 
share  modules  with  the  CREW  CHIEF  program.  Function  modules  that  are  identical  for 
COMBIMAN  and  CREW  CHIEF  are  Head  Orientation,  Interference,  Regeneration, 
Reposition  and  Visibility.  Subfunction  modules  that  are  identical  for  COMBIMAN  and 
CREW  CHIEF  are  Element  Processing,  Enfleshment  Assembly,  Head  Orientation, 
Interference,  Human  Model  Display,  Reach  and  the  Utility  functions. 

COMBIMAN  Version  9  development  began  on  two  platforms.  The  Initialization  function  and 
prototype  interface  were  developed  on  a  MicroVAX  system.  The  other  COMBIMAN 
specific  functions  and  subfunctions  were  developed  on  an  IBM  MVS  system.  The  core  and 
interface  modules  were  combined  and  initial  testing  performed  on  a  MicroVAX  system.  The 
development  and  testing  of  the  COMBIMAN  core  modules  then  migrated  to  a  Silicon 
Graphics  Personal  Iris  workstation.  Final  phase  of  core  module  development  and  testing  was 
completed  on  an  IBM  MVS  system. 

COMBIMAN  Interface 


The  prototype  interface  for  COMBIMAN  Version  9  was  developed  on  a  MicroVAX 
system.  The  interface  was  written  for  the  I-DEAS  CAD  system  using  the  I-DEAS  Ideal 
programming  language.  This  prototype  interface  was  not  host-independent.  When 
development  of  COMBIMAN  migrated  to  a  Silicon  Graphics  Personal  Iris  workstation,  the 
prototype  interface  was  converted  to  our  Common  User  Interface  (CUI). 
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3.2  Rehost  COMBIMAN  on  Other  Systems 


UDRI  was  tasked  to  develop  CAD-COMBIMAN  interfaces  for  at  least  two  additional 
CAD  systems,  taking  into  account  the  needs  of  the  users.  The  CAD  systems  selected  for 
interface  were  CATIA  V3, 1-DEAS  level  vi  (under  both  IRIX  and  SUNOS),  and  CAD  AM 
V2R21. 

3.2.1  Rehost  COMBIMAN  on  CADAM  V2  R21 


COMBIMAN  Version  9  and  Version  10  were  hosted  on  CADAM  Version  2  R21  for 
both  the  MVS  and  VM  operating  systems.  The  interface  was  performed  using  the  Interactive 
User  Exit  portion  of  the  CADAM  Access  Module,  and  through  COMBIMAN's  Common 
User  Interface  module.  The  user  interface  featured  icon-driven  menus,  on-line,  context- 
sensitive  HELP,  and  interaction  with  all  surface  and  solid  CADAM  entities.  Distribution  tapes 
were  developed  for  both  the  VM-  and  the  MVS-based  systems. 

3.2.2  Rehost  COMBIMAN  on  CATIA 


COMBIMAN  Version  9  and  Version  10  were  hosted  on  CATIA  Version  3  R2,  for 
both  the  MVS  and  AIX  operating  systems.  The  interface  was  performed  using  CATIA's 
Graphics  Interactive  Interface  (GII),  Function  Structure  Definition  (FSD),  and  the  CATIA 
Geometry  Interface  (CATGEO).  The  initial  interfaces  were  performed  by  Boeing  Computer 
Services,  at  no  charge  to  the  US  Air  Force,  working  in  close  cooperation  with  UDRI  staff. 
After  these  initial  interfaces  were  complete,  Boeing  transferred  all  source  code  to  UDRI,  and 
relinquished  all  rights  to  the  software. 

Once  the  interface  software  was  received  in-house,  UDRI  personnel  compiled  and 
linked  the  software,  and  performed  extensive  testing  on  the  COMBIMAN-CATIA  hosting. 
This  testing  included  verifications  of  the  user  and  geometry  interfaces,  as  well  as  an  evaluation 
of  the  user  interface  nomenclature  and  methods.  UDRI  corrected  any  errors  discovered 
during  verification,  and  made  changes  to  the  user  interface  to  maintain  nomenclature 
consistency  and  fidelity  to  the  CATIA  user  interface. 
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The  CATIA  interface  featured  CATIA  "panels"  for  menu  processing,  support  for 
CATIA  solids,  and  shaded  image  displays  for  the  human  model  and  the  cockpit.  The  hosting 
supported  3-D  curves,  surfaces,  and  CSG-type  solids. 

3.2.3  Rehost  COMBIMAN  on  I-DEAS 

COMBIMAN  Version  9  and  Version  10  were  hosted  under  I-DEAS  Level  VI,  on  both 
the  IRIX  (Silicon  Graphics)  and  SUNOS  (Sun)  operating  systems.  The  interface  was 
performed  using  the  I-DEAS  Director/Observer  and  I-DEAS  Universal  Files  (for  geometry 
transfer).  This  interface  was  hampered  by  the  limitations  of  the  applications  software  interface 
capabilities  of  the  I-DEAS  CAD  system.  All  data  transfer  had  to  be  done  in  batch  mode,  and 
was  executed  immediately  prior  to  running  any  CREW  CHIEF  functions.  Menus  were  limited 
both  in  the  length  of  each  menu  item  descriptor,  as  well  as  the  number  of  menu  items  allowed 
per  menu. 


3.3  Develop  TWO  Seat  Models 

During  the  course  of  this  effort,  UDRI  developed  two  ACES  II  seat  models,  of  ruse  in 
COMBIMAN  analyses.  Data  for  creating  these  models  were  gleaned  from  various  technical 
drawings,  and  created  using  the  CATIA  CAD  system.  One  seat  was  created  with  a  1 5-degree 
seatpan  angle;  the  other  was  created  with  a  30-degree  seatpan  angle.  Using  cockpit 
simulators  located  at  WPAFB,  UDRI  measured  relationships  between  a  seated  crew  member 
and  the  seat,  and  used  these  data  to  manually  manipulated  the  COMBIMAN  link  system  so 
that  these  same  relationships  existed  between  COMBIMAN  and  the  seat  model. 

During  this  contract  period,  UDRI  developed  several  models  for  seat  postures,  a 
model  for  an  ACES  II  seat,  and  a  conform  to  seat  capability.  The  posture  databases  were 
developed  for  the  CAP,  FI 6,  and  T38  workplace  analyses.  The  ACESII  seat  was  developed 
on  CAD  AM  and  input  into  the  COMBIMAN  Version  8  crew  station  database  format.  The 
conform  to  seat  capability  was  developed  for  Version  9  of  COMBIMAN  under  the  CATIA 
CAD  system.  These  development  efforts  are  consistent  with  the  requirements  listed  in  SOW 
paragraph  3.2.3. 

The  posture  databases  for  CAP,  FI 6,  and  T38  analyses  were  developed  specifically  for 
each  analysis.  These  posture  databases  were  required  to  allow  the  human  model  to  reset  to 
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these  postures  when  doing  specific  arms  only  type  reaches  under  COMB IM AN.  The  postures 
were  defined  by  using  the  Link  Table  function  under  COMB  IM  AN.  By  varying  the  link 
angles  under  the  Link  Table  function,  UDRI  was  able  to  determine  the  proper  posture  for 
each  seat  configuration.  Then,  by  modifying  the  existing  posture  databases,  UDRI  created  the 
new  text  input  files  needed  to  create  a  new  posture  database  in  direct  access  format. 
Subsequent  arms  only  reaches  then  automatically  set  the  posture  to  the  proper  orientation  for 
the  specific  analyses  being  performed. 

The  ACES  II  seat  was  input  into  CADAM  using  an  Air  Force  supplied  drawing.  The 
drawing  was  then  used  to  input  the  ACES  II  seat  into  COMBIMAN  Version  8  crew  station 
database  as  a  seat.  This  seat  was  created  using  CADAM  line  and  spline  functions  to  create  a 
3-D  drawing  from  the  2-D  drawings  presented  by  the  Air  Force. 

The  conform  to  seat  capability  was  also  developed  to  satisfy  the  requirements  of  SOW 
paragraph  3. 2. 3. 3.  Several  other  capabilities  must  be  developed  before  this  capability  can  be 
incorporated  into  the  core  software  of  COMBIMAN  The  new  capabilities  needed  are  a 
temporary  posture  database  which  would  be  created  during  the  initialization  phase  of 
COMBIMAN,  and  interface  components  which  would  define  the  seat  back  and  seat  pan 
relationships.  Then  the  conform  to  seat  capability  can  be  used  to  a'  OMBIMAN  to  lie 
against  the  seat  back  and  on  the  seat  pan  without  a  pre-defined  posture  database  for  each  seat 
configuration.  This  capability  was  developed  in  subfunction  form  and  allows  hooks  for 
compression  data  and  allows  the  flexibility  to  have  other  limbs  placed  flush  on  planar  surfaces. 

3.3.1  Develop  ACES  II  Seat  Model 

During  the  course  of  this  effort,  UDRI  developed  two  ACES  II  seat  models,  of  ruse  in 
COMBIMAN  analyses.  Data  for  creating  these  models  were  gleaned  from  various  technical 
drawings,  and  created  using  the  CATIA  CAD  system.  One  seat  was  created  with  a  15-degree 
seatpan  angle;  the  other  was  created  with  a  30-degree  seatpan  angle.  Using  cockpit 
simulators  located  at  WPAFB,  UDRI  measured  relationships  between  a  seated  crew  member 
and  the  seat,  and  used  these  data  to  manually  manipulate  the  COMBIMAN  link  system  so  that 
these  same  relationships  existed  between  COMBIMAN  and  the  seat  model. 
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3.3.2  Conform  to  Seat  Capability. 


During  this  contract  period,  UDRI  developed  a  subfunction  to  allow  a  body  segment 
or  set  of  body  segments  to  conform  to  a  planar  surface  or  set  of  planar  surfaces.  UDRI 
developed  this  subfunction  to  satisfy  the  requirements  of  paragraph  3. 2. 3. 3  of  the  SOW. 

UDRI  developed  this  subfunction  in  stages.  First,  UDRI  defined  the  subfunction  requirements 
which  include  the  subfunction  input  and  output,  any  new  data  needed  to  implement  the 
subfunction,  and  any  new  algorithms  which  need  to  be  developed  for  the  subfunction.  UDRI 
then  developed  the  mathematics  for  the  new  algorithms  identified.  Using  the  algorithm  and 
subfunction  requirements  definition,  UDRI  then  developed  the  core  control  common  area  and 
the  core  structure  for  the  subfunction.  Finally,  UDRI  developed  the  code  to  implement  the 
algorithm  developed  for  the  subfunction,  debugged  the  code,  and  tested  the  code. 

In  defining  the  subfunction  requirements,  UDRI  found  that  this  subfunction  must 
perform  three  functions.  First  the  function  should  be  able  to  compress  the  enfleshment  of  a 
body  segment  which  is  to  conform  to  a  particular  planar  surface  or  surfaces.  Second,  the 
subfimction  must  have  the  ability  to  rotate  the  distal  end  of  a  compressed  body  segment  onto  a 
plane.  Also,  the  subfunction  must  have  the  ability  to  place  the  proximal  end  of  a  body 
segment  (usually  the  mid-hip  region)  in  a  fashion  which  would  allow  the  compressed  version 
of  that  body  segment  to  be  tangent  to  two  intersecting  planar  surfaces. 

UDRI  then  developed  the  algorithms  needed  to  rotate  the  distal  end  of  a  body  segment 
onto  a  plane  and  to  place  the  proximal  end  of  a  body  segment  tangent  to  two  intersecting 
planes.  UDRI  allowed  for  later  development  of  a  compression  algorithm  which  will  not  be 
developed  until  applicable  data  are  either  gathered  or  found  in  existing  literature.  Both  of  the 
body  segment  placement  algorithms  use  3-D  vector  analysis,  trigonometry,  algebraic 
substitution,  and  quadratic  equation  solving  techniques  to  determine  the  appropriate  euler 
angles.  The  euler  angles  are  then  input  into  the  euler  angle  common  area  and  the  body 
assembly  is  recalculated  to  get  all  the  local  and  global  link  transformations  needed  for  this 
body  posture. 

The  algorithm  placing  the  distal  end  of  a  body  segment  on  a  plane  uses  the  enfleshment 
radii  and  the  joint  center  offsets  for  enfleshment  to  determine  the  enfleshment  point  on  the 
distal  end  which  is  closest  to  the  plane  on  which  the  distal  end  is  to  rest.  Now,  the  line 
between  the  center  of  enfleshment  of  the  proximal  end  of  the  link  and  the  enfleshment  point 
closest  to  the  plane  on  the  distal  end  of  the  body  segment  can  be  projected  onto  the  plane  of 
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conformity.  Now  using  parametric  equations,  and  noting  that  the  original  line  can  be  rotated 
to  force  the  enfleshment  point  to  fall  on  the  projected  line,  and  thus  on  the  plane.  Once  the 
parametric  equations  are  developed,  algebraic  substitution  was  used,  and  the  problem  became 
a  simple  quadratic  equation.  The  angle  was  then  calculated  and  placed  in  the  appropriate 
euler  angle  array  element. 

The  algorithm  placing  the  proximal  end  of  a  body  segment  tangent  to  two  intersecting 
planes  actually  looks  a  bit  simpler  on  the  surface.  Currently  it  is  assumed  that  the  only  body 
segment  which  would  be  placed  using  this  subfunction  would  be  the  mid-hip  link.  This  allows 
the  mid-hip  to  be  tangent  to  both  the  seat  back  and  the  seat  pan.  The  normal  vectors  are  used 
to  determine  the  seat  pan  and  seat  back  directions.  Then,  using  the  enfleshment  radii  of  the 
mid-hip  ellipse,  the  theoretical  mid-hip  point  is  calculated.  Then,  the  mid-hip  link  length  was 
calculated  as  well  as  the  euler  angles.  However,  since  the  hip  region  is  enfleshed  using  the 
right  hip,  left  hip,  and  the  lower  spine  links,  this  theoretical  placement  of  the  mid-hip  center  is 
only  used  to  get  the  enfleshment  close  to  being  tangent  to  both  planes  of  conformity.  The 
next  step  UDRI  used  in  developing  the  subfunction  was  to  actually  calculate  the  enfleshment 
around  the  hip,  get  the  minimum  and  maximum  values  with  respect  to  a  theoretical  seat 
coordinate  system,  and  use  these  values  to  offset  the  hip  center  of  enfleshment.  The  first  pass 
is  to  get  the  hip  center  close  to  being  tangent,  the  second  pass  gets  the  hip  tangent  since  the 
angles  do  not  change  significantly  after  the  second  pass. 

Using  the  algorithm  and  data  requirements,  UDRI  then  developed  the  core  control 
common  area  and  the  structure  for  the  subfunction  code.  The  core  common  area  contains 
two  variables,  two  one  dimensional  arrays,  and  four  two  dimensional  arrays.  The  structure 
allowed  for  development  of  eight  new  subroutines,  one  of  which  was  to  calculate  compression 
which,  as  stated  above,  has  not  been  developed. 

The  core  control  common  variables  supply  the  subfunction  with  the  necessary  input  to 
calculate  the  requested  euler  angles.  The  first  variable  in  the  control  common  determine 
whether  or  not  debug  write  statements  are  to  be  output.  Next,  the  total  number  of  body 
segments  for  which  euler  angles  are  to  be  calculated  is  input.  Then,  the  link  identifiers  for 
each  of  these  body  segments  is  stored  in  an  array  as  a  list.  The  options  for  each  link  segment 
are  then  stored  in  the  next  array  (i.e.,  compression  only  calculation,  distal  end  placement,  or 
proximal  end  placement).  The  next  two  arrays  hold  the  normal  vectors  to  the  plane(s)  on 
which  the  body  segment  is  to  be  placed.  The  final  two  input  arrays  hold  a  point  for  each  plane 
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which  is  used  with  the  previous  normal  vectors  to  fully  define  the  plane  on  which  the  body 
segment(s)  are  to  be  placed. 

The  code  structure  was  developed  using  a  structure  paralleling  the  structure  of  other 
COMBIMAN  and  CREW  CHIEF  subfunctions.  The  subfunction  executive  routine  is  used  to 
drive  the  routines  necessary  to  fulfill  the  requests  found  in  the  subfunction  core  control 
common  area.  The  first  routine  simply  checks  the  control  common  area  for  reasonable  values. 
The  next  subroutine  transfers  necessary  control  common  variables  to  subfunction  common 
areas.  Then  the  debug  routine  was  developed  to  allow  easy  debugging  when  problems  arose 
in  development  or  use  of  the  subfunction.  UDRI  put  the  hooks  in  for  a  subroutine  to 
compress  body  segments  before  the  routines  that  actually  place  the  body  segments  (i.e., 
calculate  the  euler  angles).  Then  the  routine  to  place  the  proximal  end  of  the  body  segment 
tangent  to  two  intersecting  planes  is  driven,  if  needed.  Then,  the  routine  to  calculate  the  euler 
angles  needed  for  placing  the  distal  end  of  body  segments  tangent  to  a  plane  is  driven,  if 
needed.  Finally,  the  hooks  were  put  in  for  a  routine  which  would  output  the  euler  angles  to  a 
temporary  database  for  use  by  the  reach  subfunction.  The  euler  angles  are  then  used  to 
calculate  all  the  gU1'  1  and  local  transformations  needed  to  determine  link  ends  in  local  and 
global  coordinate  auems. 

Finally,  UDRI  tested  the  subfunction  by  placing  it  in  a  temporary  position  in  the 
COMBIMAN  code.  A  temporary  file  is  used  to  fill  the  control  common  areas  since  the 
interface  for  the  initialization  function  does  not  currently  gather  the  information  necessary  for 
the  common  area.  The  largest  problem  area  was  the  hip  center  of  enfleshment  placement. 

This  is  due  to  the  way  the  hip  is  enfleshed  using  the  right  hip,  left  hip,  and  the  spine  links. 

This  problem  was  the  reason  the  enfleshed  points  of  the  hip  had  to  be  used  to  calculate  an 
adjustment  vector  and  iterate  over  the  algorithm  twice.  The  other  problem  was  the  thigh  link 
angles,  the  phi  angles  had  to  be  adjusted  to  allow  normal  postures  for  the  thighs.  UDRI  tested 
the  subfunction  for  both  the  distal  enfleshment  rotation  and  the  proximal  enfleshment 
placement  portions  of  the  algorithms.  The  hooks  for  compression  remain,  however  no  data 
have  been  collected  to  model  the  compression  during  this  contract  period. 

3.4  Maintain  COMBIMAN  Software 

Paragraph  3.1.4  required  the  COMBIMAN  software  and  documentation  be 
maintained. 
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The  official  COMBEMAN  software  is  maintained  on  a  SPARC  Station,  SUNOS.  All 
notices  of  changes  and  updates  are  given  to  the  software  manager.  The  software  manager 
updates  the  official  software  and  then  notifies  all  programmers  of  the  updates.  The  software 
is  then  updated  on  each  hardware  platform  by  the  person  responsible  for  that  specific 
platform. 

Updates  to  CAD  dependent  software  is  handled  a  little  differently.  The  CATIA 
interface  was  developed  by  Boeing  and  updates  or  modifications  to  this  interface  are  sent  to 
us  from  Boeing.  We  then  update  our  version  of  the  CATIA  interface  software.  A 
COMBIMAN/CATIA  user's  guide  is  available. 

I-DEAS  interface  software  is  updated  and  tested  on  a  SPARCStation.  Once  updates, 
modifications,  or  enhances  have  been  fully  tested,  all  programmers  are  informed  of  the 
changes.  The  ProCADAM  interface  is  compatible  with  the  CAD  AM  21  interface  and 
therefore  uses  the  same  user's  guide  as  the  COMBIMAN/CADAM  21  version. 

The  ProCADAM  interface  software  is  updated  on  a  RS6000  system.  Again,  once 
updates,  modifications,  or  enhancements  have  been  fully  tested,  all  programmers  are  informed 
of  the  changes.  The  ProCADAM  interface  is  compatible  with  the  CAD  AM  21  interface  and 
therefore  uses  the  same  user's  guide  as  the  COMBIMAN/CADAM  21  version. 

CAD  AM  21  interface  software  is  hosted  on  an  MVS  system.  At  present  we  do  not 
have  convenient  access  to  a  MVS  system  for  updates.  Previously  we  updated  the  interface 
software  in  the  same  manner  as  the  previously  mentioned  CAD  system  interfaces  to 
COMBIMAN.  A  COMBIMAN  CAD  AM  21  user's  guide  is  available. 

Unigraphics  interface  software  is  hosted  on  the  SPARCStation.  This  interface  is  still 
under  development.  At  present  there  is  no  user's  guide. 

Also  available  is  a  CAD  System  Independent  version  of  COMBIMAN.  This  software 
is  basically  the  official  core  software  and  is  maintained  on  the  SPARCStation.  A  CAD  System 
Independent  guide  is  available. 

All  user's  guides  are  kept  up-to-date.  As  enhancements  are  made  to  COMBIMAN, 
the  user's  guides  are  updated.  If  new  functions  have  been  incorporated,  the  users'  guides  have 
been  updated  accordingly. 
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SECTION  4  -  GENERAL  SUPPORT  TO  SOFTWARE  DEVELOPMENT 


In  addition  to  the  enhancements  discussed  in  Sections  2  and  3,  this  contract  required 
many  general  support  activities.  This  support  included  creating  overview  and  training  video 
tapes,  demonstrating  the  COMBIMAN  and  CREW  CHIEF  programs  for  on-base  visitors,  and 
training  novice  users  on  how  to  use  the  programs.  It  also  required  providing  design  support 
by  utilizing  these  physical  ergonomics  tools,  additional  general  enhancements  to  the  programs, 
and  software  distribution. 


4.1  Make  Video  Tapes 

The  contract  SOW  required  UDRI  to  produce  two  video  tapes.  The  first  video  tape 
was  supposed  to  be  a  ten-minute  overview  of  the  CREW  CHIEF  system  of  programs, 
including  all  major  modeling  and  graphics  capabilities.  The  second  videotape  was  supposed  to 
be  about  30  minutes  long,  and  was  intended  to  be  an  instructional  tape  of  new  users  of  CREW 
CHIEF. 

4.1.1  Overview  Video  Tape 

An  earlier  video  tape  describing  CREW  CHIEF  capabilities  was  produced  under  a 
previous  contract.  UDRI  recommended,  and  the  Air  Force  approved,  the  use  of  this  earlier 
video  tape  as  a  basis  for  the  new  overview  tape.  The  original  script  was  edited  to  take  into 
account  the  newer  capabilities  of  CREW  CHIEF.  In  addition,  UDRI  personnel  created 
several  new  demo  drawings  depicting  CREW  CHIEF  with  many  of  its  new  capabilities.  A 
film  crew  from  the  1  st  Combat  Camera  Squadron  (Det  2)  was  responsible  for  shooting  new 
footage  for  the  video  tape. 

Combat  Camera  was  also  responsible  for  the  final  editing  of  the  tape.  This  included 
merging  the  new  narrative  with  the  new  video  footage.  Some  of  the  original,  stock  footage 
was  retained,  in  order  to  reduce  costs.  Combat  Camera  also  updated  the  credits  and  the 
CREW  CHIEF  introductory  graphics. 
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4.1.2  Instructional  Video  Tape 


In  accordance  with  P00020  of  this  contract,  this  portion  of  the  effort  was  deleted. 

4.2  Apply  COMBIMAN  and  CREW  CHIEF  PROGRAMS 

During  this  contract,  UDRI  performed  analyses  of  design  problems  based  on  reach, 
strength,  and  visibility  as  well  as  obstacle  avoidance/interference.  Analyses  performed  by 
UDRI  included  reach  and  visibility  analyses  on  the  T-38,  Apache  helicopter,  C-141,  and  F-16. 
UDRI  conducted  strength  analyses  for  available  torque  for  horoscope  plug  removal.  UDRI 
also  performed  visibility  and  reach  analyses  to  evaluate  workplace  design  for  people  confined 
to  wheelchairs. 

UDRI  performed  analyses  on  a  T-38  cockpit  to  evaluate  five  potential  locations  for 
Control/Display  Units  (CDUs).  First,  UDRI  had  to  put  the  T-38  into  the  CATIA  drawing 
database.  UDRI  did  this  by  taking  the  T-38  database  in  COMBIMAN  Version  8  crew  station 
database  format  and  converting  it  to  a  CATIA  drawing  programmatically.  Then  UDRI  made 
the  final  modifications  needed  for  the  analysis  under  CATIA.  Then  the  five  locations  were 
evaluated  for  seven  body  sizes  from  the  JPATS  multi-variate  anthropometry  set  with  the  seat 
adjusted  according  to  body  size  to  give  visibility  over  the  front  panel.  The  locations  on  the 
left  console  and  the  left-side  of  the  front  instrument  panel  were  evaluated  for  left-hand 
fingertip  reach.  The  locations  on  the  right  console  and  the  right  side  of  the  front  instrument 
panel  were  evaluated  for  right-hand  fingertip  reach.  The  location  in  the  center  of  the  front 
instrument  panel  was  evaluated  for  left  and  right  hands.  Miss  distances  were  recorded  to  the 
comer  points  of  any  CDUs  which  were  not  entirely  within  reach.  UDRI  also  evaluated 
visibility  for  each  of  the  seven  subjects  to  the  CDU  locations  on  each  console  (left,  right,  and 
center)  with  one  hand  reaching  to  the  CDU  and  the  other  hand  on  the  center  stick. 

UDRI  also  performed  tandem  reach  curve  and  visibility  analyses  on  the  Apache 
helicopter.  UDRI  created  CAD  AM  drawing  files  from  the  drawings  provided  by  the 
government.  These  CAD  AM  drawings  were  then  converted  to  COMBIMAN  Version  8  crew 
station  database  format  by  using  the  CADCBM  program.  Then  UDRI  performed  analyses  for 
the  5th,  50th,  and  95th  percentile  male  Air  Force  pilots  to  determine  the  adequacy  of 
proposed  redesigns  for  both  the  pilot  and  co-pilot/gunner  cockpits.  This  problem  was 
evaluated  because  the  pilots  were  not  able  to  see  around  the  gunner  to  land  the  plane.  The 
analyses  evaluated  the  seat  location  and  its  effect  on  this  problem. 
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UDRI  performed  analysis  on  the  C-141B  SOLL II  navigator  station  to  determine 
navigator's  ability  to  see  the  Forward-Looking  Infrared  Radar  (FLIR)  display  while  reaching 
to  FLIR  controls.  UDRI  first  had  to  input  the  navigator  station  into  CAD  AM  from  supplied 
drawings.  Then,  the  CADAM  drawing  to  COMBIMAN  conversion  program  (CADCBM)  was 
run  to  put  the  drawing  into  COMBIMAN  Version  8  crew  station  database  format.  From  the 
drawing  it  was  seen  that  the  navigators  needed  to  reach  to  the  center  stick  with  their  right 
hand  and  to  controls  overhead  with  the  left  hand.  In  this  posture,  they  needed  to  look  at  the 
FLIR  display  which  was  located  near  the  floor  to  their  right.  Several  different  alternatives  to 
the  current  design  were  also  analyzed  and  recommendations  given  to  make  the  navigator 
station  more  efficient.  Visibility  analyses  were  made  for  both  men  and  women  flyers  of 
smallest  and  largest  body  sizes  for  all  suggested  alternative  designs  and  for  the  current  design. 

UDRI  performed  analysis  on  the  F-16  to  evaluate  reach  to  selected  panel  controls. 

The  subjects  were  12  named  subjects  (six  male,  six  female)  whose  dimensions  were  supplied 
by  the  customer.  Reaches  were  performed  to  38  different  controls,  with  the  left  hand  reaching 
to  left-side  panel  and  forward  panel  controls  and  right  hand  reaching  to  right  panel  controls. 
These  reaches  were  either  fingertip  or  functional  depending  on  control  type.  Results  were 
recorded  (including  miss  distances).  All  reaches  were  performed  with  arm/shoulder  mobility. 

UDRI  also  analyzed  the  F-16  to  evaluate  co-pilot's  field  of  view  while  landing.  Again 
UDRI  input  the  drawings  into  a  CADAM  drawing  database  and  use  the  CADCBM  program 
to  convert  the  drawing  to  COMBIMAN  Version  8  format.  The  pilot  obstructed  the  view  of 
the  co-pilot  during  landing.  Consequently,  the  co-pilot  had  to  lean  to  the  side  to  see  around 
the  pilot.  The  human  model  was  leaned  to  the  side  as  far  as  canopy  clearance  would  allow, 
then  visibility  plots  were  made.  Evaluations  were  performed  for  male  Air  Force  pilots  with 
the  10th,  20th,  50th,  and  90th  body  size  percentiles. 

UDRI  performed  an  analysis  using  CREW  CHIEF  which  required  the  addition  of  a 
horoscope  as  a  special  tool  under  the  CREW  CHIEF  Tool  Analysis  function.  A  horoscope 
was  digitized  into  the  CAD  system  using  supplied  dimensions.  Analyses  were  made  to 
evaluate  access  to  the  work  area  for  tool  reach.  The  minimum  and  maximum  torque  that 
could  be  applied  on  the  horoscope  plugs  were  also  analyzed.  The  analyses  were  performed 
using  6-  and  12-inch  extensions  and  long  and  regular  handles  for  a  ratchet  wrench  with  3/8- 
inch  and  half-inch  drives  using  both  regular  and  reverse  grips.  The  evaluations  were 
performed  for  the  95th  percentile  male  and  5th  percentile  female.  In  total,  96  reaches  were 
performed. 
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UDRI  performed  analysis  to  evaluate  candidate  workplace  configurations  for  people 
confined  to  wheelchairs.  Two  wheelchairs  and  two  workplaces  were  digitized  from  supplied 
measurements,  and  COMBIMAN  body  size  models  were  added  for  two  subjects.  Workplaces 
were  analyzed  for  reach  and  visibility.  Specific  design  problems  were  identified  by  the 
subjects.  The  individuals  for  whom  the  workplaces  were  being  evaluated  were  present  for 
most  of  the  evaluation,  thus,  they  were  able  to  provide  input  for  redesign  possibilities.  All 
furniture  in  the  workplaces  was  modular  and  was  entered  on  the  CAD  system  to  be  separately 
movable  pieces.  The  furniture  was  rearranged  to  provide  several  possible  solutions,  with  each 
possible  arrangement  evaluated  for  physical  accommodation  using  COMBIMAN.  Reaches  to 
bookshelves  and  keyboards,  and  knee  clearance  under  desktops  were  evaluated.  Visibility 
was  evaluated  for  computer  screens  located  in  various  locations  throughout  the  workplace. 
Alternative  configurations,  constrained  by  space  limitations  and  available  furniture,  were 
suggested  after  all  the  information  from  the  analyses  was  digested. 

4.3  Conduct  Workshop 

In  accordance  with  P00020  of  this  contract,  this  portion  of  the  effort  was  deleted. 

4.4  Enhance  Model  Capabilities 

Paragraph  3.3.6  of  the  SOW  required  UDRI  to  perform  periodic  surveys  of  CREW 
CHIEF  and  COMBIMAN  users  and  record  any  complaints,  deficiencies,  and  suggestions  for 
enhancing  the  models.  Additionally,  UDRI  was  required  to  propose  approaches  for 
overcoming  or  correcting  these  deficiencies  and  present  them  to  the  Air  Force.  This  section 
documents  the  work  performed  to  satisfy  these  requirements. 

UDRI  performed  the  initial  requirement  of  performing  a  survey  of  users  shortly  after 
commencement  of  the  contract.  Twenty-four  users  were  contacted.  Thirty-five  percent  of 
these  users  were  still  not  installed  either  due  to  time,  fiscal  constraints,  or  lack  of  proper 
environment.  At  the  time  of  this  survey,  21%  of  the  users  were  using  CAD  AM  as  their  CAD 
environment,  19%  were  using  ComputerVision,  17%  were  using  CATIA,  and  14%  were  using 
UNIGRAPHICS.  The  enhancements  suggested  from  this  survey  follow. 

One  request  from  the  user  survey  was  to  make  it  easier  to  change  parameters  for 
similar  CREW  CHIEF  runs.  For  example,  if  the  user  wants  to  check  out  the  same  lift  task 
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except  for  using  a  different  arm  during  the  lift,  a  method  should  be  available  to  change  only 
that  variable  and  have  all  the  other  variables  default  to  the  last  selected  value.  UDRI 
suggested  what  the  user  might  like  to  see  in  the  Critical  Design  Review  on  March  4,  1992. 

The  user  could  choose  whether  or  not  complete  definition  of  the  function  parameters  is 
necessary  or  if  only  a  partial  definition  of  function  parameters  is  necessary.  Under  the  partial 
parameter  definition  scenario,  UDRI  suggested  a  shorter  series  of  windows  and  menus  which 
would  allow  the  user  to  define  only  the  function  parameters  needing  redefinition.  UDRI 
developed  a  plan  to  implement  this  remedy,  including  adding  a  CUI  database  to  store  current 
selections  of  functions.  UDRI  proposed  this  remedy  to  alleviate  the  user's  exasperation  of 
having  to  redefine  all  the  parameters  of  function,  but  did  not  implement  this  remedy  during  the 
course  of  this  contract. 

Another  CUI  modification  suggested  from  the  user  survey  was  the  ability  to  have  help 
and  icon  selections  on  every  CAD  system  regardless  of  who  writes  the  interface.  UDRI 
suggested  using  a  system  independent  graphical  interface  to  allow  different  CAD  systems  to 
use  icons,  overlays,  and  help  without  doing  all  of  the  work  to  generate  the  icons  for  each 
particular  CAD  system.  To  accomplish  this  objective,  UDRI  suggested  using  a  generic  icon, 
overlay,  and  help  database  which  would  provide  the  interface  programmer  with  all  the 
necessary  information  to  generate  icon  selections  and  help  tables.  The  database  would  hold 
data  for  each  graphical  entity  in  a  format  which  would  allow  PHIGS  to  draw  such  entities. 
Each  graphical  entity  would  be  made  up  of  a  number  of  primitives,  mainly  lines  and  text, 
which  would  be  stored  in  the  database.  The  database  would  contain  header  block,  a  group 
data  block,  a  help  data  block,  a  graphics  data  block,  and  a  primitive  data  block. 

The  header  block  would  contain  the  general  information  about  the  database.  The 
CREW  CHIEF  version  number  and  database  version  number  would  be  the  first  pieces  of 
information  available  to  ensure  the  software  available  is  matched  to  the  database.  Then  the 
total  number  of  graphical  entity  groups  and  the  total  number  of  help  pages  contained  in  the 
database  would  also  be  stored  in  the  database  header  block.  The  final  piece  of  information  in 
the  header  block  would  be  the  pointers  to  the  beginning  of  each  graphical  entity  group  and  the 
pointers  to  the  beginning  of  the  help  page  data  in  the  database. 

The  group  data  block  would  contain  the  information  needed  to  display  the  icons  and 
overlays.  For  the  icons,  the  information  stored  in  this  block  would  be  the  number  of  icons  in 
the  group,  the  name  of  each  icon  in  this  group,  a  pointer  to  each  icon's  raw  data,  and  the 
graphic  transformation  matrix  for  each  icon  in  a  particular  group.  The  icon  names  allow  the 
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database  to  be  updated  quite  easily  for  each  individual  group,  and  the  raw  data  pointers  allow 
the  database  to  be  more  compact  than  a  rigid  format  would  allow.  The  graphic  transformation 
matrix  allows  the  same  graphical  entity  to  be  used  for  different  icons,  even  if  they  are  not  to 
be  placed  in  the  same  area  or  orientation  on  the  display  window.  The  information  stored  for 
the  overlays  in  this  group  would  be  the  same  information  that  was  stored  for  the  icons. 

The  help  data  block  of  this  system  independent  graphics  database  will  contain  the  help 
name  and  the  help  raw  data  pointers.  The  raw  data  pointers  will  be  used  to  obtain  the 
information  necessary  to  write  all  the  text  and  graphics  associated  with  a  particular  help  table. 
The  help  name  will  be  used  to  make  sure  data  are  not  repeated  in  the  database  just  because  the 
same  information  is  used  in  different  places  in  the  program.  Both  of  these  features  of  the  help 
block  will  allow  the  database  to  be  as  compact  as  possible  with  regards  to  the  help 
information. 

The  graphics  data  block  will  contain  all  the  graphical  entities  referenced  from  other 
portions  of  this  database.  The  name  of  each  graphical  entity  will  be  used  to  ensure  entities  are 
not  unnecessarily  repeated.  The  number  of  primitives  for  each  graphical  entity  will  also  be 
contained  in  this  block.  The  last  piece  of  information  will  be  the  pivot  point  for  each  graphical 
entity.  The  pivot  point  helps  place  and  orient  the  graphical  entity. 

The  final  block  of  data  needed  for  the  system  independent  graphics  database  is  the 
primitive  data  block  which  is  repeated  for  each  primitive  of  the  graphical  entity.  For  each 
primitive,  the  primitive  type,  number  of  records  needed  to  define  the  primitive,  the  attributes 
associated  with  the  primitive,  and  the  raw  data  for  the  primitive  will  be  stored  in  this  block. 
Note  that  one  primitive  can  be  used  by  more  than  one  graphical  entity,  again  saving  space  in 
the  database  and  allowing  easier  creation  of  new  graphical  entities  within  the  database. 

Another  request  from  the  users  was  to  allow  for  addition  of  more  populations  to  the 
CREW  CHIEF  anthropometry  database.  UDRI  proposed  a  series  of  modifications  to  the 
current  anthropometric  database  maintenance  programs  to  enable  maximum  flexibility  in  the 
implementation  of  this  user  request.  The  modifications  involved  were  intended  to  accomplish 
the  following: 

Eliminate  hard  coding  of  anthropometric  regression  equations. 

Streamline  the  program  for  calculating  anthropometry  (CALCANTH  program). 

Incorporate  use  of  the  Anthropometry  Regression  database  in  CALCANTH. 
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Eliminate  the  program  that  performed  the  final  anthropometry  conversion 
(CNVANTH  program). 

-  Allow  for  processing  of  multiple  populations. 

UDRI  implemented  these  modifications  by  developing  three  new  programs  which 
output  the  anthropometric  data  and  regressions  used  as  input  by  CALCANTH.  The  three 
programs  UDRI  created  are  AMPREG,  VBLREG,  and  BLNREG.  AMP REG  was  developed 
to  create  the  anthropometry  regression  database  which  contains  one  or  more  populations, 
each  consisting  of  ten  basic  regressions  and  anthropometric  data  (stature,  weight,  and  arm 
length)  for  the  ten  percentiles  of  CREW  CHIEF.  VBLREG  was  developed  to  create  the 
variable  regression  database  containing  sets  of  additional  regressions  required  for  construction 
of  the  man-model.  Thus,  different  sets  could  be  available  for  the  different  populations. 
BLNREG  was  developed  to  create  a  set  of  regressions  to  calculate  body  link  lengths.  These 
regressions  are  used  for  all  populations. 

UDRI  developed  this  set  of  programs  to  allow  populations  to  be  entered  through  the 
Anthropometry  Regression  and  Variable  Regression  databases.  The  populations  are  then 
automatically  incorporated  into  CREW  CHIEF'S  Posture  Anthropometry  database  by  running 
CALCANTH  and  INITDBAS. 

To  finish  implementation  of  multiple  populations,  UDRI  modified  ANTEXE  and  the 
CREW  CHIEF  interface  to  allow  access  to  the  new  populations,  and  INITDBAS  was  changed 
to  create  the  final  CREW  CHIEF  format  of  the  initialization  database.  Then,  UDRI  added  to 
new  populations  to  the  database  and  accessed  all  three  populations  from  CREW  CHIEF  for 
verification.  The  new  populations  added  were  the  Army  population  from  the  ANSUR  88 
survey  and  the  Air  Force  Officers  population  obtained  from  the  subsets  of  the  1968  survey  of 
Air  Force  women  and  the  1965  survey  of  Air  Force  men. 

Another  request  from  the  users  was  addition  of  multiple  technicians.  Since  the  Air 
Force  did  not  want  UDRI  to  spend  the  time  necessary  for  true  addition  of  multiple 
technicians,  UDRI  simply  suggested  to  the  users  that  they  save  models  into  their  drawings  and 
then  run  another  model  for  multiple  technicians.  This  will  at  least  allow  the  user  to  look  at 
accessibility  problems  when  using  multiple  technicians.  However,  it  will  not  give  them  any 
indication  of  strength  characteristics  of  multiple  technicians  or  the  effect  one  technician  has  on 
the  other  during  a  maintenance  task.  These  characteristics  would  require  a  lot  of  new  strength 
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studies  and  would  require  a  large  amount  of  recoding  to  implement  them  even  if  the  studies 
were  completed. 

One  of  the  most  frequently  requested  enhancements  was  the  ability  of  CREW  CHIEF 
to  interact  with  solid  models  contained  in  drawings.  UDRI  has  developed  a  plan  to  include 
solids  processing  in  CREW  CHIEF.  The  plan  was  developed  for  the  CDR,  and  consisted  of 
breaking  the  solids  down  to  NURB  (non-uniform  rational  b-spline)  surfaces  and  then 
tessellating  the  surfaces  into  triangular  facets.  These  facets  could  then  be  used  by  the  CREW 
CHIEF  interference  algorithm  instead  of  the  linearization  scheme  currently  used.  This  method 
would,  however,  require  the  user  to  run  a  function  to  generate  a  database  with  all  the 
triangular  facets  needed  to  represent  a  particular  drawing.  Once  this  function  has  been  run, 
then  the  user  benefits  from  the  use  of  triangular  facets  instead  of  lines  which  have  holes 
between  them  that  CREW  CHIEF  body  parts  may  be  able  to  sneak  through  in  certain 
particular  cases.  Also,  since  no  more  linearization  needs  to  take  place  during  the  interference 
analysis,  and  since  the  software  no  longer  needs  to  interface  with  the  CAD  database,  the 
interference  function  may  actually  take  less  time  to  perform  its  analysis  even  though  the 
analysis  will  be  more  accurate  with  the  tessellated  surfaces. 

Although  UDRI  has  not  implemented  the  CDR  plan  into  CREW  CHIEF  yet,  the  plan 
was  developed  completely  enough  to  add  it  in  the  future.  Also,  in  the  CATIA  interface,  a 
solids  interface  was  developed  by  Boeing  using  the  old  linearization  scheme,  and  that  interface 
was  implemented  into  the  CATIA  version  of  CREW  CHIEF.  UDRI  also  added  solids 
processing  into  the  UNIGRAPHICS  and  IDEAS  versions  of  CREW  CHIEF.  These  two 
versions  were  developed  during  this  contract  period  by  UDRI. 

The  IDEAS  version  of  CREW  CHIEF  preprocesses  the  drawing  at  the  beginning  of 
the  CREW  CHIEF  run.  If  you  want  to  run  CREW  CHIEF  with  another  drawing,  it  is 
necessary  to  start  CREW  CHIEF  over  again.  UDRI  used  the  software  available  from  IDEAS 
to  generate  a  tessellated  version  of  the  drawing  database  and  stored  the  generated  facets  in  a 
temporary  database  for  future  use  by  the  obstacle  avoidance  subfunction  and  the  Visibility 
function. 

The  UNIGRAPHICS  version  of  CREW  CHIEF  uses  the  NURBS  surface  breakdown 
of  the  solid  as  the  starting  point  for  representing  the  solid  in  CREW  CHIEF.  Once  the  surface 
is  in  NURBS  form,  it  is  linearized  and  the  line  segments  generated  are  passed  to  CREW 
CHIEF.  For  the  surfaces  in  UINGRAPHICS,  it  was  necessary  to  change  the  form  of  each 
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surface  to  a  NURBS  form  of  the  surface  in  order  to  be  able  to  process  the  myriad  of  surfaces 
available  in  UNIGRAPHICS.  This  technique  allowed  UDRI  to  make  the  CAD  database 
interface  to  UNIGRAPHICS  one  of  the  most  complete  CAD  database  interfaces  CREW 
CHIEF  has  available.  The  technique  parallels  the  technique  developed  for  the  CDR  where 
tessellation  will  be  used  to  break  surfaces  down  to  facets  instead  of  line  segments  as  done 
here. 


The  CATIA  solids  interface  created  by  Boeing  is  also  a  linearization  technique  similar 
to  the  UNIGRAPHICS  technique.  UDRI  implemented  this  solids  interface  to  CREW  CHIEF 
and  also  implemented  later  versions  of  Boeing's  solids  interface  to  CREW  CHIEF.  This 
interface  still  has  some  CATIA  elements  that  are  not  passed  to  CREW  CHIEF,  since  there  is 
no  easy  way  to  transform  the  elements  in  the  way  that  UNIGRAPHICS  was  done.  However, 
most  of  the  commonly  used  elements  are  now  available  for  CREW  CHIEF  processing  during 
interference  and  visibility  analyses. 

UDRI  also  presented  the  Air  Force  with  another  list  of  possible  enhancements  for 
CREW  CHIEF  during  the  PDR.  The  modifications  UDRI  suggested  during  this  contract  are 
the  Input/Output  Management  (IOM)  subfunction,  a  data  restructure,  the  Link  Table 
Function,  the  Grasp  Function,  database  conversion  programs,  prompt  standardization. 
Visibility  Function  enhancements,  the  Add  User  Defined  Tool  Function,  CREW  CHIEF  reach 
enhancements,  and  mobility  enhancements.  Most  of  these  suggestions  have  been  designed, 
developed,  and  integrated  into  CREW  CHIEF,  however,  some  of  these  have  not  been 
integrated  into  CREW  CHIEF  during  this  contract. 

The  IOM  subfunction  was  developed  to  control  the  flow  of  critical  CREW  CHIEF 
information.  The  first  piece  of  information  is  the  general  human  model  information.  This 
information  contains  the  general  characteristics,  and  the  position,  link  system,  and  enfleshment 
information  needed  to  fully  define  the  human  model.  The  tool  information  contains  the 
general  characteristics  and  the  general,  link  system,  enfleshment,  reach,  and  other  information 
needed  to  reconstruct  the  tool,  and  the  enveloped  information  needed  for  performing  the  work 
envelope  function.  The  last  piece  of  information  controlled  by  the  subfunction  is  the  object 
information  for  the  Manual  Materials  Handling  functions.  Dimensions,  orientation,  and 
placement  are  the  critical  pieces  of  information  saved  by  the  IOM  subfunction  for  the  object. 
Currently,  the  IOM  subfunction  consists  of  two  subroutines  which  are  used  separately  to 
control  the  information  described  above.  UDRI  plans  to  combine  these  routines  into  a  regular 
subfunction  in  the  future,  since  the  two  routines  are  inextricably  linked  to  one  another. 
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Another  in-house  suggested  enhancement  to  CREW  CHIEF  is  the  Grasp  function. 

The  Grasp  function  was  developed  as  a  function  different  from  the  Reach  function  in  that  the 
user  is  able  to  define  the  type  of  grasp  the  human  model  is  to  simulate.  The  Grasp  function 
was  developed  in  four  phases.  The  first  phase  was  the  development  of  the  Common  User 
Interface  (CUI)  portion  of  the  Grasp  function  (used  as  an  interface  between  the  software 
dependent  on  the  CAD  system  and  the  core  software  to  gather  the  function  parameters  from 
the  user).  The  second  phase  of  development  was  actually  implementing  the  grasp  algorithms 
as  new  core  software.  Since  the  Grasp  function  was  being  developed  on  the  CAD  AM  CAD 
system,  icons,  help  pages,  and  overlays  were  also  created  for  the  Grasp  function.  The  fourth 
and  final  phase  of  the  Grasp  function  development  was  the  testing  and  validation  (and 
subsequent  modifications  to  fix  any  software  bugs  found). 

UDRI  developed  the  CUI  interface  for  the  Grasp  to  allow  an  easy  method  to  obtain 
the  parameter  definitions  for  the  function.  The  code  developed  here  simply  defines  the 
prompts,  accepts  the  function  parameters  chosen  by  the  user  under  the  CAD  dependent 
portion  of  the  program,  and  passes  these  values  to  the  core  function  software.  The  first 
couple  of  routines  written  for  the  CUI  software  for  Grasp  simply  determine  the  number  of 
arms  and  which  arms  are  to  be  used  during  the  analysis.  The  next  routine  was  written  to 
determine  the  type  of  object  which  is  to  be  grasped  (i.e.,  knob,  edge,  or  handle).  The  next 
four  routines  developed  were  used  to  define  the  knob,  handle,  or  object  which  is  to  be 
grasped.  Then,  finally,  the  general  choices  of  mobility  type,  obstacle  avoidance,  and  display 
type  were  called  from  the  Grasp  function's  CUI  driver  routine.  Then  the  Grasp  function  was 
called  from  the  CUI  routine  and  control  passed  to  the  core  software. 

Once  the  CUI  software  was  developed,  UDRI  developed  the  core  software  for  the 
Grasp  function.  The  core  algorithm  first  checks  the  parameters  passed  from  the  CUI.  If  all 
the  parameters  are  correct,  the  core  proceeds  to  transfer  the  control  common  variables  to  the 
appropriated  core  common  blocks  and  then  initializes  any  other  variables  needed  for  the  Grasp 
(based  on  the  control  common  variables  input  from  CUI).  Once  all  the  variables  are  set,  the 
reach  subfunction  is  called  and  the  defined  reaches  are  attempted  (along  with  interference  if 
the  user  has  selected  obstacle  avoidance).  Then  the  variables  set  by  the  reach  subfunction  are 
processed  to  display  to  the  user  whether  or  not  a  successful  grasp  has  been  completed.  If  the 
grasp  was  unsuccessful,  then  the  reasons  for  the  model's  inability  to  grasp  are  displayed.  If  the 
grasp  is  successful,  then  the  human  model  is  displayed  in  the  final  reach  posture  needed  to 
perform  the  grasp. 
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The  next  phase  of  development  for  the  Grasp  function  was  to  develop  the  icons, 
overlays,  and  help  pages  needed  to  give  the  user  a  graphical  indication  as  to  what  each  prompt 
is  defining.  The  most  important  icons  for  the  grasp  are  the  icons  which  show  the  user  what 
each  type  of  grasp  looks  like.  The  other  icons  and  help  pages  have  been  created  for  other 
functions,  and  only  had  to  be  incorporated  into  the  Grasp  function. 

The  final  phase  of  the  Grasp  function  development  was  the  test  and  validation  phase. 
Every  path  of  prompts  was  tested  to  make  sure  all  the  information  was  being  processed 
properly  at  both  the  CUI  and  core  levels.  This  also  tested  all  the  CAD  dependent  routines 
which  were  used  by  the  CUI  for  this  function.  Any  bugs  that  were  found  were  immediately 
corrected  and  any  paths  that  the  modification  could  have  had  an  impact  on  were  retested. 
Finally,  after  the  model  was  fully  tested  with  no  errors,  the  Grasp  function  was  incorporated 
into  the  Version  3  software  of  CREW  CHIEF. 

During  this  contract,  UDRI  also  developed  the  Link  Table  function.  The  Link  Table 
function  was  developed  to  enable  the  user  total  control  over  the  orientation  of  a  link  with  the 
only  constraint  being  mobility  limits  for  that  link.  Like  the  Grasp  function,  the  Link  Table 
function  was  developed  in  four  phases.  The  first  phase  was  the  development  of  the  Common 
User  Interface  (CUI)  portion  of  the  Link  Table  function.  The  second  phase  of  development 
was  implementing  the  Link  Table  algorithms  as  new  core  software.  Again,  like  the  Grasp 
function,  the  Link  Table  function  was  being  developed  on  the  CAD  AM  CAD  system,  so 
icons,  help  pages,  and  overlays  were  also  created  for  the  Grasp  function.  The  fourth  and  final 
phase  of  the  Link  Table  function  development  was  the  testing  and  validation  (and  subsequent 
modifications  to  fix  any  software  bugs  found). 

UDRI  developed  the  CUI  interface  for  the  Link  Table  function  to  allow  an  easy 
method  to  obtain  the  parameter  definitions  for  the  function.  UDRI  only  needed  a  few  routines 
to  develop  the  prompts  and  inputs  needed  for  Link  Table.  The  first  prompt  was  the  general 
choice  of  a  display  type  used  by  many  of  the  other  functions  in  CREW  CHIEF.  UDRI  then 
created  several  prompts  which  allow  the  user  to  choose  which  link  to  orient  and  how  to  orient 
that  link  by  keying  in  the  euler  angles  for  the  link.  Then  the  Link  Table  function  is  called  from 
the  CUI  routine  and  control  is  passed  to  the  core  software.  When  control  is  returned  to  CUI, 
the  user  may  choose  to  save  the  new  orientation,  reject  the  new  orientation,  and  resume  or 
exit  the  Link  Table  function. 
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Once  UDRI  finished  the  GUI  portion  of  the  Link  Table  function,  UDRI  developed  the 
core  software  for  the  Link  Table  function.  UDRI  developed  core  routines  which  check  the 
range  of  the  input  common  control  variables  passed  from  the  CUI.  Then  UDRI  developed  the 
routine  which  transfers  the  core  common  control  variables  to  the  core  common  areas  that  will 
actually  use  the  values  set  by  the  CUI.  Then,  UDRI  developed  the  routines  which  used  the 
Mobility  subfunction  to  check  the  input  euler  angles  to  see  if  they  were  in  the  range  of  the 
human  model's  mobility.  UDRI  then  developed  the  software  which  outputs  the  human  model 
using  the  enfleshment  and  display  subfunctions  and  also  displays  an  arrow  if  the  mobility 
bounds  have  been  exceeded  by  the  user's  choice  of  euler  angles.  The  final  core  developed  by 
UDRI  was  the  ability  to  save  the  link  orientation  changes  made  by  the  user,  if  the  user  decides 
to  save  the  changes. 

The  next  piece  of  development  for  the  Link  Table  function  by  UDRI  was  the 
development  of  icons,  overlays,  and  help  pages  for  the  CAD  AM  version  of  CREW  CHIEF. 
The  main  development  here  was  the  creation  of  the  help  tables  to  help  the  user  understand 
how  the  euler  angles  they  input  would  be  used  to  change  the  orientation  of  the  link  to  be 
moved.  An  overlay  was  generated  for  the  menu  determining  which  link  to  reorient.  UDRI 
developed  this  overlay  so  it  is  easier  to  see  which  euler  angles  go  with  which  link. 

The  final  phase  of  the  Link  Table  function  development  was  the  test  and  validation 
phase.  Every  path  of  prompts  was  tested  to  make  sure  all  the  information  was  being 
processed  properly  at  both  the  CUI  and  core  levels.  This  also  tested  all  the  CAD  dependent 
routines  which  were  used  by  the  CUI  for  this  function.  Any  bugs  that  were  found  were 
immediately  corrected  and  any  paths  that  the  modification  could  have  had  an  impact  on  were 
retested.  Finally,  after  the  model  was  fully  tested  with  no  errors,  the  Link  Table  function  was 
incorporated  into  the  Version  3  software  of  CREW  CHIEF. 

UDRI  has  made  several  enhancements  to  CREW  CHIEF'S  Visibility  function.  UDRI 
has  modified  several  routines  to  take  care  of  plotting  problems  in  Visibility.  UDRI  added  the 
Aitoff  projection  as  a  choice  of  plot  type  (as  opposed  to  the  rectangular  projection  plot). 
Finally,  UDRI  added  the  ability  to  pick  more  than  one  overlay  during  an  analysis  so  users  are 
not  forced  to  run  the  Initialization  function  several  times  to  get  the  clothing  overlays  they  need 
to  analyze  using  the  Visibility  function. 

UDRI  found  that  when  large  elements  in  the  CAD  database  are  linearized  in  Visibility 
to  allow  for  the  distortion  that  takes  place  when  converting  rectangular  coordinates  into  angle 
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space,  the  FORTRAN  array  size  limitations  are  such  that  the  entire  element  cannot  be  plotted. 
For  now,  UDRI  has  allowed  the  processing  to  stop  when  the  array  bounds  are  exceeded,  since 
this  is  a  FORTRAN  limitation  that  cannot  be  changed.  UDRI  has  also  devised  a  plan  to  create 
a  database  to  store  the  workplace  design  geometry  which  would  allow  this  problem  to  be 
eliminated.  Due  to  time  constraints,  however,  UDRI  was  not  able  to  implement  this  design 
during  the  contract  period. 

UDRI  also  found  some  other  software  bugs  in  the  Visibility  function  plot  software. 
UDRI  found  that  line  segments  were  not  displayed  if  they  formed  an  angle  of  more  than  90 
degrees  with  the  horizontal.  Due  to  round-off  error  however,  it  was  possible  for  some 
vertical  lines  to  form  an  angle  of  more  than  90  degrees  (i.e.,  90.20  degrees).  UDRI  removed 
this  90  degree  restriction.  Another  bug  was  found  in  the  clipping  algorithm.  The  previous 
algorithm  clipped  an  entire  line  segment  even  if  it  only  lay  partially  outside  the  plot  windows. 
This  caused  large  line  segments  to  be  clipped  totally  out  causing  significant  loss  of  geometry. 
UDRI  modified  this  algorithm  to  clip  only  the  portion  of  the  line  segment  that  lay  outside  the 
plot  window. 

UDRI  added  a  new  plot  capability  called  the  Aitoff  s  projection  to  the  Visibility 
function.  Military  Standard  850  requires  that  visibility  plots  for  cockpits  be  either  rectilinear 
plots  or  Aitoff  s  equal  area  projection  of  a  sphere.  UDRI  modified  the  user  interface  for 
Visibility  to  include  selection  of  the  desired  type  of  visibility  plot  (rectilinear  or  Aitoff).  Then, 
core  routines  were  modified  or  added  to  calculate  the  Aitoff  s  projections  under  CREW 
CHIEF.  UDRI  also  developed  icons  for  this  part  of  the  user  interface  for  the  CAD  AM 
version  of  CREW  CHIEF.  The  icons  were  used  to  show  the  user  how  the  rectilinear  and 
Aitoff  projections  would  look.  The  icons  were  actually  miniature  rectilinear  and  Aitoff  plots. 

The  final  modification  UDRI  made  to  the  Visibility  function  was  the  additional 
capability  to  select  more  than  one  overlay.  Previously,  users  were  forced  to  run  Initialization 
if  they  wanted  to  get  a  different  clothing  overlay  in  the  visibility  function.  Therefore,  if  the 
user  needed  several  clothing  overlays  in  visibility,  one  run  of  Initialization  and  one  run  of 
Visibility  were  necessary  for  each  clothing  type  needed.  UDRI  modified  the  CUI  software, 
the  core  software,  and  the  Visibility  database  to  allow  the  increased  flexibility  of  being  able  to 
select  multiple  clothing  overlays  by  running  only  one  Visibility  Analysis. 

UDRI  also  enhanced  the  Reach  subfunction  during  this  contract  period.  UDRI 
modified  this  subfunction  to  allow  trunk  interference  calculations  in  addition  to  the  arm 
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interference  calculations.  UDRI  also  added  the  ability  to  define  the  direction  vector  for  a 
functional  and  a  finger-tip  reach.  UDRI  also  modified  the  trunk  positioning  algorithm  in  the 
reach  subfunction.  In  addition,  UDRI  performed  some  developmental  work  for  a  straight 
wrist  algorithm. 

UDRI  modified  the  reach  subfunction  to  allow  trunk  interference  to  correct  problems 
occurring  with  the  subfunction  using  arms  only  interference  checking.  CREW  CHIEF  was 
bending  at  the  trunk  to  avoid  arm  interference,  but  at  the  expense  of  having  the  whole  torso 
interfere  with  the  workplace.  To  accomplish  this  additional  checking,  UDRI  had  to  modify 
the  interference  subfunction  also.  The  interference  subfunction  modifications  allow  the 
programmer  the  flexibility  to  check  for  interference  with  any  body  part(s).  Then  UDRI 
modified  the  reach  subfunction  to  tell  the  interference  subfunction  to  check  for  all  the  upper 
body  segments.  Then,  the  reach  subfunction  performs  trunk  positioning  via  a  binary  search 
for  an  unobstructed  trunk  position.  If  the  trunk  is  pitched  fully  forward  and  interference  is  not 
found,  then  the  trunk  remains  in  that  position.  However,  if  interference  is  detected,  then  the 
trunk  is  positioned  backward  iteratively,  each  time  moving  the  trunk  half  as  much  as  the 
previous  movement  until  an  optimal  trunk  position  is  found,  or  until  it  is  determined  that 
interference  cannot  be  avoided. 

UDRI  also  modified  the  functional  and  finger-tip  reach  algorithms  in  the  reach 
subfunction.  The  main  thrust  of  this  change  was  to  allow  the  user  to  define  the  attach 
direction  for  the  reach  during  functional  and  finger-tip  reaches.  UDRI  modified  the  code  to 
allow  a  consistent  and  precise  grip  when  reaching  to  a  knob  or  pushing  a  button.  UDRI  then 
test  the  code  by  performing  reaches  to  knobs  and  buttons  at  different  locations  and 
orientations  relative  to  the  human  model.  UDRI  found  through  this  testing  that  reaches  to 
nearby  locations  were  mostly  correct  while  reaches  to  some  farther  locations  were  not  as 
precise.  UDRI  is  still  developing  plans  for  integrating  the  new  algorithm  with  the  existing 
algorithm. 

UDRI  performed  one  other  modification  of  the  reach  algorithm.  UDRI  noticed  the 
wrist  was  bending  when  the  natural  reach  would  have  been  to  keep  the  wrist  straight.  UDRI 
developed  a  prototype  straight  wrist  reach  by  drastically  modifying  the  reach  algorithm 
relating  to  the  wrist.  Tests  were  performed  using  over  fifty  different  reach  scenarios.  This 
included  both  right  and  left  hand  reaches  in  various  locations  around  the  human  model.  The 
tests  included  high,  medium,  and  low  reaches.  In  every  instance  the  reach  performed  as 
desired  and  looked  natural. 
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UDRI  modified  two  areas  of  concern  in  the  mobility  subfunction.  First,  UDRI  found 
problems  with  the  upper  arm  abduction  and  adduction  motions.  Additionally,  UDRI  found 
problems  with  the  upper  arm  rotations.  UDRI  modified  the  subfunction  to  correct  these 
problems. 

The  problem  with  the  upper  arm  abduction  and  adduction  were  traces  to  two  specific 
causes.  First,  the  angles  allowed  for  arm  movement  in  the  four  principal  directions  were  not 
large  enough.  Also,  Additional  directional  limits  were  required  to  model  the  upper  arm  joint 
motion  accurately.  UDRI  expanded  the  model  to  include  eight  principal  directions,  with  linear 
interpolation  used  to  obtain  intermediate  angular  limits. 

UDRI  also  found  a  problem  with  the  upper  arm  rotations.  Typically,  the  rotations  are 
given  a  continuous  allowable  range.  Any  joint  angle  whose  twist  falls  outside  this  range  is 
automatically  reset  to  the  closest  boundary  value.  However,  since  inverse  trigonometric 
functions  are  generally  used  to  calculate  these  values,  and  these  functions  are  single-valued 
within  an  interval  of  2  n,  the  specified  rotational  range  of  motion  was  limited  to  values  within 
the  interval  [-7T  %].  New  data  proved  this  limitation  was  not  valid,  because  some  of  the  actual 
ranges  crossed  this  boundary.  Therefore,  UDRI  modified  the  software  to  account  for  multi¬ 
valued  inverses. 

UDRI  also  wrote  and  modified  all  of  the  database  conversion  programs  for  CREW 
CHIEF  and  COMBIMAN.  CREW  CHIEF  databases  often  must  be  transferred  from  one 
system  to  another.  In  order  to  perform  these  transfers  systematically,  UDRI  wrote  programs 
to  convert  the  direct  access  files  to  character  files.  These  character  files  can  then  be 
transferred  to  the  different  systems.  UDRI  also  wrote  the  programs  to  take  the  character  files 
back  to  direct  access  files  on  the  system  to  which  the  files  have  been  transferred. 

UDRI  created  a  common  area  for  these  database  conversion  programs  which  holds  the 
path  name  of  the  databases  referenced  by  the  conversion  programs.  Then  an  interactive 
procedure  used  to  run  the  conversion  programs  was  developed  to  allow  conversions  to  be 
more  user  friendly  and  also  give  the  user  the  option  of  running  one  database  conversion  at  a 
time  or  all  of  the  database  conversions  at  once.  All  of  the  changes  made  to  the  database 
conversion  programs  were  tested  as  well  as  the  interactive  procedure  developed  to  run  the 
conversion  programs.  These  programs  now  exist  as  in  house  software  to  help  alleviate  the 
transition  from  one  platform  to  another. 
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During  this  contract,  UDRI  also  developed  a  more  consistent  prompt  for  the  Common 
User  Interface  (CUI).  UDRI  found  that  many  of  the  prompts  were  different  between 
functions  and,  more  noticeably,  between  CAD  systems.  In  order  to  standardize  the  prompts, 
UDRI  formed  a  committee  whose  task  was  to  identify  inconsistencies  and  resolve  these 
inconsistencies  in  a  fashion  that  would  allow  the  most  compatibility  between  CAD  systems. 

As  a  result,  the  UDRI  committee  determined  the  following  must  occur  to  give  the 
most  concise  and  uniform  prompting  between  interfaces  and  functions: 

-  Use  the  phrase  "human  model"  instead  of  "man-model." 

-  Use  the  key  word  "select"  for  all  menu  selection  prompts. 

Use  the  word  "pick"  for  all  geometry  selection  prompts. 

-  Use  the  phrase  "key"  instead  of  "key-in." 

-  Use  the  key  word  "define"  for  prompts  which  call  for  identifying  a  point  using  any 
of  the  numerous  methods  supported  by  individual  CAD  systems. 

Shorten  prompts,  as  much  as  possible,  while  maintaining  comprehensibility. 

-  Prompts  were  changed  to  no  longer  be  platform-specific  in  their  wording. 

-  Place  the  most  important  information  at  the  beginning  of  each  prompt. 

These  recommendations  were  then  implemented  by  changing  all  the  prompts  in  the  CUI 
source  code.  These  changes  were  then  thoroughly  tested  for  all  of  the  functions.  Once 
testing  was  successfully  completed,  these  changes  became  part  of  the  official  CUI  source 
code. 


Another  set  of  enhancements  UDRI  implemented  during  this  contract  period  were 
modifications  to  the  Tool  Analysis  function  and  its  interface.  UDRI  fixed  invalid  placement  of 
a  few  sockets  on  the  wrench,  resolved  inconsistencies  between  the  Work  Envelope  and  Tool 
Analysis  Functions,  and  fixed  the  improper  placement  of  the  file  in  the  workplace.  UDRI  also 
modified  the  Tool  Analysis  function  interface  to  allow  for  a  user  selection  of  the  User  Defined 
Tool  class.  This  last  change  consisted  of  making  sure  a  tool  class  had  tools  in  it  before 
presenting  it  to  the  user  for  selection.  UDRI  also  chained  the  tool  database  to  allow  CREW 
CHIEF  to  use  a  power  grasp  on  all  the  wrenches  to  resolve  discrepancies  between  how  the 
strength  data  were  collected  and  how  CREW  CHIEF  represents  the  strength  data. 
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4.5  Configuration  Management  of  Software 


UDRI  managed  the  development  of  the  COMBIMAN  and  CREW  CHIEF  programs 
by  using  a  radical  waterfall  life  cycle  approach  to  software  development.  The  waterfall  life 
cycle  approach  to  software  development,  see  Figure  16,  is  broken  into  four  steps.  The  four 
steps  of  this  methodology  are  Analysis,  Design,  Code  and  Test.  Analysis  of  the  problem 
occurs  during  the  Analysis  step.  The  design  of  the  solution  occurs  in  the  second  step.  Coding 
of  the  solution  occurs  in  the  third  step.  The  final  step  is  a  rigorous  testing  of  the  software.  In 
the  classic  waterfall  life  cycle,  you  must  complete  each  step  before  the  next  step  begins.  In  a 
radical  approach  to  the  waterfall  life  cycle  software  development,  work  on  later  steps  can 
begin  before  work  completes  on  earlier  steps.  The  major  benefit  of  a  radical  approach  is  that 
you  can  see  intermediate  results  much  sooner  than  in  a  conservative,  or  classical,  waterfall  life 
cycle  approach.  UDRI  achieved  a  radical  approach  by  using  the  waterfall  life  cycle  for  each 
module  in  the  COMBIMAN  and  CREW  CHIEF  programs. 


Figure  16.  Waterfall  Life  Cycle  Approach  to 
Software  Development 


The  waterfall  life  cycle  was  implemented  through  a  series  of  13  standing  technical 
committees.  Through  the  technical  committees,  and  established  programming  standards, 
UDRI  carried  out  a  radical  waterfall  life  cycle  software  development  methodology.  All  of  our 
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programming  personnel  are  involved  as  members  of  various  committees.  The  standing 
technical  committees  are  described  in  the  following  paragraphs. 

Software  Standards 


The  Software  Standards  committee  is  responsible  for  deciding  the  standards  by 
which  everyone  should  program.  This  includes  the  ways  in  which  our  modules 
interact.  This  committee  also  decides  the  structure  of  individual  subroutines.  The 
Software  Standards  committee  must  approve  any  violation  of  established  standards. 

Function  Requirements 

The  Function  Requirements  committee  must  approve  development  plans  for 
any  new  COMBIMAN  or  CREW  CHIEF  function  or  subfunction.  This  committee  is 
responsible  for  ensuring  that  the  proposed  capabilities  are  applicable  to  address 
adequately  the  needs  of  the  proposed  module.  Approval  from  this  committee  must  be 
received  before  proceeding  to  any  other  committees. 

Mathematical  Models 


The  Mathematical  Models  committee  must  approve  all  mathematical  models 
used  in  COMBIMAN  and  CREW  CHIEF.  Furthermore,  this  committee  must  also 
approve  all  statistical  models  used  in  COMBIMAN  and  CREW  CHIEF.  This 
committee  does  not  need  to  approve  candidate  models  that  are  undergoing  testing. 
This  committee  must  approve  all  final  models. 

Core  Control  Commons 


The  Core  Controls  Commons  committee  is  responsible  for  approving 
FORTRAN  COMMON  BLOCKS.  This  committee  must  approve  all  of  the  function 
and  subfunction  Control  Commons  for  COMBIMAN  and  CREW  CHIEF.  The  Core 
Controls  Commons  committee  is  usually  the  second  stop  along  the  road  to  completing 
a  new  function  or  subfunction. 
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Core  Structure  and  Nomenclature 


The  Core  Structure  and  Nomenclature  committee  is  responsible  for 
maintaining  the  integrity  of  the  modular  structure  of  the  programs.  This  committee  is 
also  responsible  for  maintaining  the  integrity  of  the  naming  conventions  used  in 
COMBIMAN  and  CREW  CHIEF.  Also,  this  committee  approves  subroutine  titles 
and  objectives. 

Database  Design 

The  Database  Design  committee  is  responsible  for  reviewing  and  approving  all 
database  designs  for  the  COMBIMAN  and  CREW  CHIEF  programs.  This  includes 
any  output  to  any  FORTRAN  logical  unit,  other  than  the  Function  Log  and  Diagnostic 
output  units.  Preliminary  database  designs  also  should  go  to  this  committee  for 
discussion. 

Common  Areas  Committee 

The  Common  Areas  committee  is  responsible  for  approving  all  non-control  and 
final  data  common  block  variables.  This  includes  function  level  and  global  variables. 
Also  included  are  those  variables  that  are  COMBIMAN  or  CREW  CHIEF  specific. 

Utility  and  Subfunction  Modification 

The  Utility  and  Subfunction  Modification  committee  must  approve  any 
additional  utility  subroutines.  Also,  this  committee  approves  changes  to  existing 
subfunctions  and  utility  subroutines.  Note  that  this  committee  does  not  approve  new 
subfunctions.  New  subfunctions  must  undergo  the  same  approval  as  new  functions. 

Code  Development 

The  Code  Development  committee  is  responsible  for  ensuring  that  all  code 
written  meets  written  programming  standards. 
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User  Interface  Design 


The  User  Interface  Design  committee  is  responsible  for  approving  all  user 
interface  designs.  User  interfaces  are  some  of  the  most  important  modules  in  the 
COMBIMAN  and  CREW  CHIEF  programs.  Because  of  this,  great  care  is  taken  to 
ensure  that  the  user  interface  for  each  function  is  designed  properly.  Before 
implementation  the  contract  monitor  reviews  each  user  interface. 

CAD  Dependent  Routines 

The  CAD  Dependent  Routines  committee  is  responsible  for  approving  all  new 
CAD  dependent  routines.  This  committee  is  also  responsible  for  approving 
modifications  to  the  argument  lists  for  existing  CAD  dependent  routines.  CAD 
database  input  routines  are  also  under  the  jurisdiction  of  this  committee.  This 
committee  is  not  responsible  for  the  coding  of  a  subroutine  for  a  particular  interface. 
The  CAD  Dependent  Routines  committee  functions  to  establish  the  standards  by 
which  the  COMBIMAN  and  CREW  CHIEF  programs  communicate  with  all  CAD 
systems. 

Function  Testing  and  Validation 

The  Function  Testing  and  Validation  committee  is  responsible  for  ensuring  that 
the  COMBIMAN  and  CREW  CHIEF  programs  are  as  bug  free  as  possible. 

CAD  System  Interfaces 

The  CAD  System  Interfaces  committee  must  approve  the  basic  development 
plan  for  all  new  CAD  interfaces.  Whenever  possible  the  CUI  is  used  as  the  method  of 
interfacing  to  all  CAD  systems.  This  committee  approves  any  deviation  from  the  CUI. 

In  an  attempt  to  increase  the  efficiency  of  documentation  generation,  some  portions  of 
the  in-line  documentation  were  automated.  A  computer  aided  Header  Generator  was 
developed,  as  well  as  a  computer  aided  Hierarchy  Chart  Generator.  The  following  paragraphs 
describe  these  automated  documentation  tools. 
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Computer  Aided  Header  Generator 


The  Computer  Aided  Header  Generator  was  developed  to  provide  a  simpler 
way  of  updating  internal  documentation  for  the  COMBIMAN  and  CREW  CHIEF 
programs.  It  also  allows  programmers  to  check  the  status  of  our  internal 
documentation.  This  ensures  us  that  the  latest  revisions  are  referenced.  This  program 
was  developed  in  FORTRAN  on  an  IBM  mainframe  running  the  MVS  operating 
system.  It  provides  a  calls  list,  called  by  list,  common  area  titles,  subroutine  titles, 
subroutine  objectives,  revision  numbers  and  revision  dates. 

Computer  Aided  Hierarchy  Chart  Generator 

Programmers,  of  COMBIMAN  and  CREW  CHIEF,  require  hierarchy  charts  of 
the  functions  and  subfunctions.  A  computer  aided  method  for  generating  these  charts 
was  developed  on  an  IBM  mainframe  running  the  MVS  operating  system.  The 
program  uses  a  list  of  called  subroutines  for  every  subroutine  in  COMBIMAN  and 
CREW  CHIEF.  The  charts  were  designed  to  show  different  symbols  based  on 
subroutine  type.  For  example,  hexagons  enclose  executive  subroutines,  circles  enclose 
utility  subroutines  and  rectangles  enclose  lower  level  subroutines. 

UDRI  also  developed  a  new  file  structure  for  the  COMBIMAN  and  CREW  CHIEF 
programs.  We  have  implemented  this  file  structure  on  all  Unix  platforms.  The  file  structure  is 
implemented  in  a  tree  structure  with  a  root  directory  and  subdirectories  representing  each 
major  software  module.  The  objective  of  this  file  system  structure  is  to  reflect  the  modular 
structure  of  the  COMBIMAN  and  CREW  CHIEF  programs.  Another  goal  of  the  file 
structure  is  to  increase  our  ability  to  efficiently  rehost  our  software  on  other  Unix  platforms. 

A  final  goal  is  to  ease  the  sharing  of  software  modules  between  COMBIMAN  and  CREW 
CHIEF.  Figure  17  is  a  diagram  of  the  Unix  file  structure. 

The  Unix  "make"  facility  is  used  to  control  compiling  and  linking  of  the  COMBIMAN 
and  CREW  CHIEF  modules  on  all  Unix  systems.  The  "make"  facility  uses  a  series  of 
description  files  (called  Makefiles).  The  Makefiles  describe  the  relationships  among  the 
program  modules.  These  relationships,  or  dependencies,  are  used  to  ensure  that  all  modules 
are  current.  This  helps  minimize  errors  and  saves  valuable  programmer  time. 
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4.5.1  Software  Language 


During  software  development  efforts,  UDRI  used  ANSI  Standard  FORTRAN  77 
while  coding  CREW  CHIEF  and  COMBIMAN  core  code  and  interface  code.  No 
nonstandard  code  was  written.  For  in-house  software,  UDRI  used  software  languages 
deemed  most  efficient  for  the  particular  development  effort  at  hand. 

4.5.2  Modular  Structure  for  Software 

The  COMBIMAN  and  CREW  CHIEF  software  consists  of  structured  modules.  There 
are  several  standing  committees  responsible  for  overseeing  the  modular  structure.  Each 
software  module  comprises  many  FORTRAN  subroutines.  The  development  of  the 
underlying  FORTRAN  code  followed  documented  in-house  programming  standards.  The  use 
of  these  standards  ensures  that  program  modules  have  very  little  dependency  on  the  operation 
of  the  internal  details  of  other  modules. 

Several  standing  committees  exist  to  oversee  the  development  of  COMBIMAN  and 
CREW  CHIEF  program  modules.  Adherence  to  the  committee  procedure  ensures  the 
development  of  modularized  and  standardized  software.  The  following  paragraphs  give  a 
brief  description  of  the  committees  responsible  for  modular  program  development. 

Software  Standards 


The  Software  Standards  committee  is  responsible  for  deciding  the  standards  by 
which  everyone  should  program.  This  includes  the  ways  in  which  our  modules 
interact.  This  committee  also  decides  the  structure  of  individual  subroutines.  The 
Software  Standards  committee  must  approve  any  violation  of  established  standards. 

Function  Requirements 

The  Function  Requirements  committee  must  approve  development  plans  for 
any  new  COMBIMAN  or  CREW  CHIEF  function  or  subfunction.  This  committee  is 
responsible  for  ensuring  that  the  proposed  capabilities  are  applicable  to  address 
adequately  the  needs  of  the  proposed  module.  Approval  from  this  committee  must  be 
received  before  proceeding  to  any  other  committees. 
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Core  Control  Commons 


The  Core  Controls  Commons  committee  is  responsible  for  approving 
FORTRAN  COMMON  BLOCKS.  This  committee  must  approve  all  of  the  function 
and  subfunction  Control  Commons  for  COMBIMAN  and  CREW  CHIEF.  The  Core 
Control  Commons  committee  is  usually  the  second  stop  along  the  road  to  completing 
a  new  function  or  subfunction. 

Core  Structure  and  Nomenclature 


The  Core  Structure  and  Nomenclature  committee  is  responsible  for 
maintaining  the  integrity  of  the  modular  structure  of  the  programs.  This  committee  is 
also  responsible  for  maintaining  the  integrity  of  the  naming  conventions  used  in 
COMBIMAN  and  CREW  CHIEF.  Also,  this  committee  approves  subroutine  titles 
and  objectives. 

Common  Areas  Committee 


The  Common  Areas  committee  is  responsible  for  approving  all  common  blocks 
except  control  and  final  data  common  block  variables.  This  includes  function  level  and 
global  variables.  Also  included  are  those  variables  that  are  COMBIMAN  or  CREW 
CHIEF  specific. 

Utility  and  Subfunction  Modification 

The  Utility  and  Subfunction  Modification  committee  must  approve  any 
additional  utility  subroutines.  Also,  this  committee  approves  changes  to  existing 
subfunctions  and  utility  subroutines.  Note  that  this  committee  does  not  approve  new 
subfunctions.  New  subfunctions  must  undergo  the  same  approval  as  new  functions. 

Code  Development 

The  Code  Development  committee  is  responsible  for  ensuring  that  all  code 
written  meets  written  programming  standards. 
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The  COMBEMAN  and  CREW  CHIEF  program  modules  (functions  and  subfunctions) 
contain  many  FORTRAN  subroutines.  While  each  function  or  subfunction  is  unique,  there  are 
many  operations  that  are  common  among  program  modules.  FORTRAN  subroutines 
implement  each  of  these  common  operations.  The  following  paragraphs  describe  the  most 
abundant  of  the  common  subroutines. 

USR  Subroutines 

The  USR  subroutines  are  the  core  function  entry  points.  These  subroutines 
manage  all  processing  within  the  core  functions.  The  CUI  accesses  the  USR 
subroutines.  If  required  the  CAD  system  interface  software  may  access  the  USR 
subroutines  directly.  (Refer  to  the  "CREW  CHIEF  CAD  System  Interface  Guide"  for 
more  details.) 

BUG  Subroutines 

The  BUG  subroutines  output  debug  control  variables.  All  COMBIMAN  and 
CREW  CHIEF  functions  and  subfunctions  receive  control  information  through  control 
common  blocks.  There  are  times  when  a  programmer  needs  to  produce  an  audit  trail 
of  the  control  variable  values.  The  BUG  subroutines  send  the  control  variables  to  the 
COMBIMAN  or  CREW  CHIEF  diagnostics  log  file. 

CHK  Subroutines 

The  CHK  subroutines  check  interface  control  variables.  These  subroutines 
check  the  control  variables  passed  to  the  core  functions  from  the  CAD  interface  to 
determine  if  the  values  are  within  acceptable  ranges.  The  CHK  subroutines  will 
display  any  invalid  value  and  the  variable's  acceptable  range. 

PRT  Subroutines 


The  PRT  subroutines  print  function  parameters.  The  COMBIMAN  and 
CREW  CHIEF  programs  produce  an  audit  trail  containing  all  parameters  selected  by 
the  user  and  function  results.  The  PRT  subroutines  are  responsible  for  printing  the 
audit  trail. 
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YIN  Subroutines 


The  VIN  subroutines  are  responsible  for  variable  initialization.  Our  standards 
require  that  modules  initialize  their  variables.  Also,  these  routines  initialize  variables 
passed  to  subfunctions.  The  VIN  subroutines  do  the  initializations. 

VXF  Subroutines 


The  VXF  subroutine  control  variable  transfer.  FORTRAN  common  blocks 
pass  control  variables  to  functions  and  subfunctions.  Our  standards  require  the 
moving  of  control  data  to  the  appropriate  module  level  or  global  common  area.  It  is 
the  responsibility  of  the  VXF  subroutines  to  transfer  module  parameters. 

EXE  Subroutines 


The  EXE  subroutines  are  the  subfunction  executive  subroutines.  These 
subroutines  are  the  entry  points  for  the  subfunction  modules.  The  EXE  subroutines 
manage  all  processing  within  the  subfunctions.  Both  function  and  subfunction  level 
modules  access  these  entry  points. 

SUC  Subroutines 


The  SUC  subroutines  process  successful  reaches.  These  subroutines  calculate 
and  generate  strength  table  values.  The  SUC  subroutines  also  include  human  model 
display  generation. 

I  NT  Subroutines 


The  INT  subroutines  process  interference.  These  subroutines  process  the 
unavoidable  interference  information.  This  information  includes  the  generation  of 
interference  arrows.  The  INT  subroutines  call  the  message  generation  subroutines. 
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MIS  Subroutines 


The  MIS  subroutines  process  missed  distances.  These  subroutines  output 
messages  and  the  human  model  when  a  missed  distance  occurs.  The  MIS  subroutines 
are  part  of  functions  that  perform  reaches. 

POS  Subroutines 


The  POS  subroutines  control  posture  initialization.  These  subroutines  reset 
lower  body  posture  for  full  body  mobility.  Push  and  Pull  function  use  the  POS 
subroutines. 

TBL  Subroutines 


The  TBL  subroutines  generate  strength  tables.  These  subroutines  display 
tables  of  strength  data.  The  data  contain  limits  and  predicted  percentile  values. 

TXT  Subroutines 


The  TXT  subroutines  generate  strength  table  text.  The  TBL  subroutines  use 
the  TXT  subroutines  to  generate  the  text  used  in  the  strength  tables. 

LIM  Subroutines 


The  LIM  subroutines  generate  text  for  strength  limits.  These  subroutines 
generate  MEL-STD  strength  limits  for  Hold,  Lift  and  Carry  functions. 

STR  Subroutines 


The  STR  subroutines  calculate  strength.  These  subroutines  calculate  strength 
values  for  percentile  values.  The  STR  subroutines  send  strength  values  to  the  SUC 
subroutines. 
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SRV  Subroutines 


The  SRV  subroutines  set  Reach  subfunction  variables.  Functions  that  perforr 
reaches  call  the  SRV  subroutines. 

BAR  Subroutines 


The  BAR  subroutines  process  bare  handed  reaches.  These  are  materials 
handling  subroutines.  When  reaching  to  an  object  without  handles,  the  modules  call 
the  BAR  subroutines. 

HDL  Subroutines 


The  HDL  subroutines  process  reaches  to  handles.  These  are  materials  handling 
subroutines.  The  HDL  subroutines  calculate  the  variables  needed  to  reach  a  handle. 

The  entire  modular  software  structure  is  built  upon  FORTRAN  source  code.  The 
development  of  the  source  code  followed  written  programming  standards.  The  programming 
standards  include  general  appearance  of  the  code.  This  covers  cod  ntation  and  a 
systematic  way  of  labeling  code  and  input/output  statements.  Our  programming  standards 
also  cover  the  parameter  passing  among  subroutines  and  modules.  Our  standards  clearly 
define  the  use  of  FORTRAN  common  blocks,  to  store  global  and  local  information.  Our 
standards  extensively  cover  Source  code  documentation. 

4.5.3  Embedded  Comments 


Paragraph  3.3.7  required  the  code  to  be  self-explanatory  with  interval  comments  and 
in-line  header  block. 

All  sources  require  a  header  block  which  contains  a  title,  objective,  calls  list,  called  by 
list,  parameters  passed  (input  vs  output),  and  revision  data.  A  Header  Block  program  was 
created  to  extract  this  information  from  each  source  to  be  used  in  program  documentation. 
This  program  reduced  the  time  it  took  to  do  internal  documentation  of  each  subroutine. 

The  title  of  a  subroutine  is  a  short  description  of  the  functionality  of  a  subroutine.  It  is 
intended  to  be  a  mnemonic  aid  to  the  programmer,  and  so  should  somehow  reflect  the  three- 
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letter  descriptor  at  the  end  of  each  subroutine  name.  The  objective  of  a  subroutine  is  a  more 
detailed  description  of  its  functionality.  This  description  should  include  the  names  of  any 
mathematical  or  algorithmic  methods  used,  as  well  as  any  special  considerations  which  should 
be  taken  into  account  when  using  the  subroutine. 

The  called  by  and  calls  portion  of  the  header  list  the  name  and  title  of  each  subroutine 
which  is  called  by,  or  calls,  the  subroutine  being  described. 

The  parameters  passed  list  should  have  a  complete  description  of  any  variables  passed 
into  the  subroutine  through  the  parameter  list.  These  descriptions  should  be  concise  and 
informative.  Parameters  should  be  divided  into  input  and  output  parameters. 

The  common  areas  portion  contains  a  list  of  all  common  areas  and  their  titles,  needed 
for  the  execution  of  the  subroutine.  Common  areas  should  be  titled  to  mneumonically  reflect 
both  the  three-letter  description  and  the  contents  of  the  common. 

The  revision  data  and  number  are  used  to  track  the  history  of  a  subroutine.  The  date 
listed  here  should  be  the  date  that  the  subroutine  was  last  modified.  The  revision  number 
indicates  the  total  number  of  revisions  the  subroutine  has  undergone. 

Programming  standards  have  been  incorporated,  especially  in  documenting  each 
subroutine  internally.  Comments  within  the  body  of  the  code  should  be  clear  and  concise,  and 
should  be  separated  from  FORTRAN  statements  by  one  blank  comment  describing  what  that 
block  is  doing.  Within  each  block,  every  call,  iterative  loop,  group  of  assignment  statements, 
or  branch  should  be  commented  immediately  prior  to  the  statement.  In  addition,  the  use  of 
any  constants  within  a  subroutine  should  be  documented  immediately  prior  to  their  use.  These 
statement-level  comments  should  be  easily  distinguishable  from  the  block-level  comments,  and 
should  describe  a  low-level  algorithm  for  the  block  of  code. 

Each  database  created  contains  a  header  block  as  the  first  record.  This  record  gives 
the  program  number  and  name,  database  number  and  name,  and  a  brief  description  of  the 
records  contained  in  the  database. 

4.5.4  Interaction  with  other  Software 


By  using  a  modular  structure,  UDRI  was  able  to  separate  software  which  was 
dependent  upon  a  particular  CAD  system  from  the  core  modules  of  COMBIMAN  and  CREW 
CHIEF.  The  CAD  routines  were  clearly  identified  and  a  user's  guide  was  written  for  CAD 
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interface  programmers  to  follow  when  interfacing  CREW  CHIEF  and  COMBIMAN  to  a  new 
CAD  system.  Specific  system  requirements  were  also  identified  as  deemed  necessary. 

4.5.5  Modification  to  Existing  Software 
Tool  Restructuring 

The  tool  restructuring  began  with  the  creation  of  a  new  tool  database.  Before  the  new 
tool  database,  the  CREW  CHIEF  program  read  tool  data  from  four  different  files.  The  new 
tool  database  is  a  hierarchical  schema  set  up  in  a  single  concise  file.  The  new  database  makes 
it  easier  to  add  new  tools  to  the  database.  Another  advantage  is  that  the  new  structure  allows 
the  building  of  the  user  interface  from  database  information. 

The  development  of  the  new  tool  database  required  the  development  of  a  new 
software  module  to  read  the  database.  The  Tool  Input  (TIN)  subfunction  allows  the  CUI  and 
core  modules  access  to  user  prompts  and  tool  data.  Because  the  database  contains  the 
interface  prompts  and  menus,  we  created  new  CUI  subroutines. 

The  new  CUI  subroutines  process  tools  without  knowledge  of  the  type  or  class  of 
tool.  This  generic  approach  led  to  a  more  concise  set  of  CUI  subroutines.  The  need  to  put 
tool  specific  data  in  the  CUI  code  no  longer  exists. 

The  original  core  tool  modules  (TAN  and  TOL)  contained  many  instances  of  tool  data 
residing  in  the  source  code.  Many  of  these  subroutines  were  rewritten  due  to  the 
development  of  the  new  tool  database.  This  eliminated  most  of  the  instances  of  hardcoded 
tool  data. 

Core  Common  Area  Restructuring 

UDRI  is  in  the  process  of  restructuring  the  core  common  areas.  The  main  purpose  is 
to  allow  the  development  of  an  Input/Output  Manager  (IOM)  subfunction  module.  A  pair  of 
utility  subroutines  currently  handle  the  functions  of  the  IOM  module.  The  size  of  the  CREW 
CHIEF  program,  and  the  added  complexity  due  to  the  development  of  Version  9 
COMBIMAN,  required  the  two  utility  subroutines  evolve  into  a  subfunction. 
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The  elimination  of  structure  violations  is  another  purpose  for  common  area 
restructuring.  Software  modules  are  only  permitted  to  use  common  areas  local  to  their 
modules  or  global  common  blocks.  Some  modules  violate  this  structure.  The  Tool  Input 
subfunction  is  the  most  notable  culprit. 

4.5.6  Software  Structure 


The  COMBIMAN  and  CREW  CHIEF  programs  comprise  several  modules.  Each 
module  performs  a  specific  function  or  subfunction.  A  function  module  performs  complete 
analysis  or  generation  (Initialization,  Tool  Analysis,  etc.).  Subfunction  modules  perform 
specific,  complex  tasks,  required  for  the  completion  of  functions. 

There  are  more  than  twenty  functions  making  up  the  COMBIMAN  and  CREW 
CHIEF  programs.  There  are  four  main  types  of  functions  Generation,  COMBIMAN 
Activities,  CREW  CHIEF  Tasks,  and  Accessibility,  Visibility  and  Current  Configuration.  The 
following  paragraphs  briefly  describe  the  functions. 

Generation  functions 

The  Generation  functions  are  common  to  both  COMBIMAN  and  CREW  CHIEF. 
There  are  five  generation  functions.  They  are  Initialization,  Regeneration,  Head  Orientation, 
Link  Table  and  Reposition. 

Initialization 


The  Initialization  function  generates  and  displays  the  human  model.  The  user 
selects  the  body  size,  clothing,  posture  and  orientation.  The  human  model,  while 
placed  in  the  user's  drawing,  is  not  a  permanent  part  of  the  drawing.  This  prevents  the 
programs  from  corrupting  the  user's  drawing. 

Regeneration 

The  Regeneration  function  regenerates  the  human  model  display.  The 
programs  use  enfleshment  data  from  the  last  successful  positioning  operation.  The 
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Regeneration  function  provides  the  user  the  opportunity  to  change  the  model's  display 
type  and  the  user's  viewpoint. 

Head  Orientation 


The  Head  Orientation  function  lets  the  user  specify  where  the  human  model 
will  try  to  look.  The  human  model  will  only  turn  its  head  as  far  as  mobility  constraints 
allow.  Upon  completion,  the  display  shows  the  human  model  looking  toward  the 
selected  location. 

Link  Table 


The  Link  Table  function  allows  the  user  to  change  the  posture  of  the  human 
model.  The  program  presents  the  user  with  a  table  of  angles  for  sixteen  links  in  the 
human  model's  link  system.  The  user  changes  the  phi,  theta  and  psi  values  to 
reposition  the  link  system.  The  function  checks  each  change  to  prevent  the  entering  of 
unrealistic  values  and  to  ensure  that  the  change  is  within  joint  mobility  limits. 

Reposition 

The  Reposition  augments  functions  that  position  the  human  model.  Sometimes 
the  analysis  requires  that  the  program  place  the  human  model  in  an  uncommon 
position,  or  a  position  requiring  the  movement  of  arms  and  legs.  The  reposition 
function  allows  the  movement  of  up  to  twelve  body  segments.  To  protect  from 
creating  unrealistic  positions,  the  function  enforces  mobility  constraints. 

COMBIMAN  Activity  Functions 

The  COMBIMAN  activity  functions  are  analysis  functions  that  are  used  for  a  seated 
operator.  There  are  three  COMBIMAN  Activity  functions.  They  are  Reach,  Strength  and 
Reach  Envelope. 

Reach 


The  COMBIMAN  Reach  function  allows  the  evaluation  of  an  aircrew 
member's  capabilities  to  reach  controls.  Controls  in  this  context  consist  of  handles, 
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rudder  pedals,  and  toggle  switches,  rotary  dials  and  push  buttons.  Because  of  mobility 
limits,  the  human  model  reaches  toward  the  control  location  with  realistic  joint 
mobility. 

Strength 

The  Strength  function  allows  the  evaluation  of  an  aircrew  member's  capabilities 
to  reach  and  operate  controls.  Controls  in  this  context  consist  of  handles,  rudder 
pedals,  and  toggle  switches,  rotary  dials  and  push  buttons.  Because  of  mobility  limits, 
the  human  model  reaches  toward  the  control  location  with  realistic  joint  mobility.  This 
function  assumes  that  a  control  is  within  the  operator's  reach  before  predicting 
strength  capabilities. 

Reach  Envelope 

The  Reach  Envelope  function  decides  if  a  control  panel  lies  inside,  intersects 
with  or  lies  outside  a  crew  member's  maximum  arm-reach  envelope.  The  evaluation 
depends  on  body  size,  clothing  type,  restraint  type  and  control  type  (grip  type).  The 
Reach  Envelope  function  produces  a  reach  envelope  in  3-D  space  and  then  computes 
the  intersection  of  the  reach  envelope  with  the  selected  control  panel(s). 

CREW  CHIEF  Tasks 


The  CREW  CHIEF  tasks  are  functions  that  pertain  to  a  maintenance  technician. 

There  are  nine  functions  in  this  category.  The  functions  are  Tool  analysis,  Connector  analysis 
and  Manual  Materials  Handling  (Carry,  Hold,  Lift,  Push,  Pull,  Reach  and  Grasp). 

Tool  Analysis 

The  Tool  analysis  function  evaluates  the  ability  to  reach  with  a  tool.  This 
includes  the  ability  to  reach  around  obstacles.  This  function  displays  strength 
capability  (upon  successful  tool  reach).  The  CREW  CHIEF  Tool  Analysis  function 
contains  a  220-piece  tool  box.  The  types  of  tools  included  are  wrenches  with  sockets, 
wrenches  without  sockets,  screwdrivers,  pliers  and  miscellaneous  tools  such  as 
hammers. 
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Connector  Analysis 


The  Connector  analysis  function  evaluates  the  strength  capability  of  a 
technician  to  secure  an  electrical  connector  at  a  specified  location.  The  evaluation 
depends  on  the  grip  used  and  connector  size.  The  results  appear  in  a  table  of  strength 
capabilities. 

Materials  Handling 

The  Materials  Handling  functions  evaluate  the  capabilities  of  a  technician  to 
handle  objects  in  the  workplace.  There  are  seven  skills  evaluated  by  this  function. 

The  skills  are  lift,  push,  pull,  hold,  carry,  reach  and  grasp.  Often  the  objects  are  the 
line  replaceable  units  (LRUs).  Strength  data  are  available  for  carry,  hold,  lift,  push  and 
pull  tasks. 

Accessibility.  Visibility  and  Configuration  Functions 

The  Accessibility  functions  (Interference  and  Work  Envelope)  allow  the  user  to 
analyze  the  interference  between  the  human  model  and  the  drawing  elements.  The 
Visibility  function  allows  the  user  to  plot  a  projection  of  the  workplace.  The 
Configuration  function  displays  information  about  the  human  model. 

Interference  Function 


The  Interference  function  checks  interference  between  the  human  model  and 
elements  in  the  workplace.  Interference  checks  the  whole  body  or  portions  of  the 
body.  Interference  checking  works  with  or  without  a  tool.  Interference  checking  is 
performed  using  the  current  posture  configuration  and  position  of  the  human  model. 
The  function  marks  points  of  interference  with  3-D  arrows. 

Work  Envelope  Function 

The  Work  Envelope  function  presents  a  graphic  display  of  the  volume  of  space 
required  to  operate  a  tool.  This  function  also  shows  the  volume  of  space  required  for 
the  movement  of  an  object.  Work  Envelope  is  a  quasi-dynamic  interference  check 
used  only  by  the  CREW  CHIEF  program. 
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Visibility  Function 


The  Visibility  function  plots  a  projection  of  visual  azimuth  and  elevation  line- 
of-sight  angles  to  elements  in  the  drawing.  The  plot  can  be  either  a  rectilinear  or  an 
Aitoff  projection.  The  plot  depicts  the  visual  field  as  seen  by  the  human  model.  This 
function  has  the  option  of  a  plot  from  a  user  defined  viewpoint. 

Current  Configuration  Function 

The  Current  Configuration  function  displays  the  parameter  values  used  in  the 
execution  of  the  COMBIMAN  and  CREW  CHIEF  programs. 

Subfunctions 


The  COMBIMAN  and  CREW  CHIEF  functions  rely  upon  the  subfunction  modules. 
These  modules  perform  various  complex  tasks.  Such  tasks  include  interference  calculation 
and  enfleshment  assembly.  There  are  fifteen  subfunction  modules.  The  following  paragraphs 
briefly  describe  the  subfunctions. 

ANT  Subfunction 


ANT  is  the  anthropometry  input  subfunction.  This  subfunction  reads  and 
processes  human  model  anthropometric  data. 

CCI  Subfunction 


CCI  is  the  element  processing  subfunction.  This  subfunction  inputs  drawing 
elements  into  COMBIMAN  and  CREW  CHIEF  programs. 

DSP  Subfunction 


DSP  is  the  display  human  model  subfunction.  This  subfunction  produces 
graphical  output  data  for  human  model  enfleshment  display. 
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ENF  Subfunction 


ENF  is  the  enfleshment  assembly  subfunction.  This  subfunction  positions  the 
mesh  file  node  data  used  to  enflesh  the  human  model. 

HEP  Subfunction 


HED  is  the  head  orientation  subfunction.  This  subfunction  controls  head 
positioning  for  several  COMBIMAN  and  CREW  CHIEF  functions. 

INF  Subfunction 


INF  is  the  interference  subfunction.  This  subfunction  finds  the  interference 
between  the  human  model  and  the  work  place. 

LEG  Subfunction 


LEG  is  the  leg  reach  subfunction.  This  subfunction  performs  an  iterated 
inverse  kinematic  reach. 

MOB  Subfunction 

MOB  is  the  mobility  subfunction.  This  subfunction  determines  the  range  of 
motion  for  the  human  model  link  system. 

MMH  Subfunction 


MMH  is  the  Materials  Handling  subfunction.  This  subfunction  performs 
operations  common  to  the  Materials  Handling  functions. 

RCH  Subfunction 


RCH  is  the  arm  reach  subfunction.  This  subfunction  performs  an  iterated 
inverse  kinematic  reach. 
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RED  Subfunction 


RED  is  the  read  enfleshment  subfunction.  This  subfunction  initializes  the  mesh 
files  used  to  enflesh  the  human  model. 

SIT  Subfunction 

SIT  is  the  COMBIMAN  initialization  input  subfunction.  This  subfunction 
reads  the  COMBIMAN  posture,  from  the  initialization  database,  based  upon  seat  type. 

TIN  Subfunction 


TIN  is  the  tool  input  subfunction.  This  subfunction  uses  the  tool  database. 

The  tool  database  contains  tool  sizing  data  and  user  interface  information. 

TOL  Subfunction 

TOL  is  the  CREW  CHIEF  tool  reach  subfunction.  This  subfunction  performs 
reaches  with  specified  tools. 

IJTI  Subfunction 

The  UTI  module  is  a  collection  of  utility  subroutines.  These  subroutines 
perform  operations  that  are  required  by  many  functions  and  subfunctions.  For 
example,  UTI  subroutines  perform  matrix  multiplication,  gaussian  elimination,  etc. 

CAD  Interfaces 

There  are  two  ways  to  interface  COMBIMAN  and  CREW  CHIEF  programs  to  CAD 
systems.  The  first  method  is  for  the  interface  to  directly  access  the  COMBIMAN  and  CREW 
CHIEF  core  functions,  accomplished  by  passing  parameters  through  FORTRAN  common 
blocks.  The  second  method  is  by  using  the  Common  User  Interface  (CUI).  CUI  is  the  outer 
shell  of  the  COMBIMAN  and  CREW  CHIEF  host  independent  code.  This  shell  contains  the 
interface  logic.  CUI  retrieves  information  from  the  user  by  calling  a  small  set  of  CAD 
dependent  subroutines.  When  the  CAD  system  interface  allows  the  use  of  the  CUI,  it  is  the 
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preferred  method  of  interfacing  to  COMBIMAN  and  CREW  CHIEF.  The  following 
paragraphs  briefly  describe  the  COMBIMAN  and  CREW  CHIEF  CAD  interfaces. 

CATIA 


This  interface  uses  the  CATIA  Function  Structure  Definition  (FSD)  module  to  layout 
the  menus.  FSD  prevents  the  use  of  CUI.  The  CATIA  interface  also  uses  the  Graphics 
Interactive  Interface  and  CATIA  Geometry  Interface  modules.  The  COMBIMAN  and  CREW 
CHIEF  CATIA  interfaces  run  on  IBM  RS6000  workstations  running  the  A IX  operating 
system,  IBM  mainframe  computers  running  the  MVS  operating  system. 

CAD  AM 

This  interface  uses  the  CAD  AM  Interactive  User  Exit  (IUE)  facility.  IUE  permits  the 
use  of  CUI.  The  COMBIMAN  and  CREW  CHIEF  CAD  AM  interfaces  run  on  IBM  RS6000 
workstations  running  the  AIX  operating  system,  IBM  mainframe  computers  running  the  MVS 
operating  system  and  IBM  minicomputers  running  the  VM  operating  system. 

I-DEAS 


This  interface  uses  the  I-DEAS  Director/Observer  facility.  Director/Observer  permits 
the  use  of  CUI.  The  COMBIMAN  and  CREW  CHIEF  interfaces  to  I-DEAS  Level  VI  run  on 
a  Sun  workstation  running  SUNOS  operating  system.  The  COMBIMAN  interface  to  I-DEAS 
Level  VI  and  the  COMBIMAN  and  CREW  CHIEF  interfaces  to  I-DEAS  Level  V  run  on  a 
Silicon  Graphics  workstation  running  the  IRIX  operating  system. 

Unigraphics 

This  interface  uses  the  Unigraphics  User  Function  interface  facility.  User  Function 
permits  the  use  of  CUI.  The  COMBIMAN  and  CREW  CHIEF  CAD  AM  interfaces  to 
Unigraphics  run  on  a  Sun  workstation  running  the  SUNOS  operating  system. 
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Module  Name 

Function/Subfunction 

Program 

Initialization  (INI) 

Function 

Both 

Regeneration  (REG) 

Function 

Both 

Head  Orientation  (HDO) 

Function 

Both 

Head  Orientation  (HED) 

Subfunction 

Both 

Link  Table  (LKT) 

Function 

Both 

Reposition  (RPN) 

Function 

Both 

Reach  (REA) 

Function 

COMBIMAN 

Reach  (REC) 

Function 

CREW  CHIEF 

Reach  (RCH) 

Subfunction 

Both 

Strength  (STR) 

Function 

COMBIMAN 

Reach  Envelope  (REN) 

Function 

COMBIMAN 

Tool  (TAN) 

Function 

CREW  CHIEF 

Tool  Reach  (TOL) 

Subfunction 

CREW  CHIEF 

Module  Name 

Function/Subfunction 

Program 

Tool  Input  (TIN) 

Subfunction 

CREW  CHIEF 

Connector  (CTR) 

Function 

CREW  CHIEF 

Materials  Handling  (MMH) 

Subfunction 

CREW  CHIEF 

Hold  (HLD) 

Function 

CREW  CHIEF 

Pull  (PLL) 

Function 

CREW  CHIEF 

Push  (PSH) 

Function 

CREW  CHIEF 

Grasp  (GSP) 

Function 

CREW  CHIEF 

Carry  (CRY) 

Function 

CREW  CHIEF 

Lift  (LFT) 

Function 

CREW  CHIEF 

Work  Envelope  (WRK) 

Function 

CREW  CHIEF 

Interference  (ITF) 

Function 

Both 

Interference  (INF) 

Subfunction 

Both 

Configuration  (CFG) 

Function 

Both 

Visibility  (VIS) 

Function 

Both 

Anthropometry  Input  (ANT) 

Subfunction 

Both 

Leg  Reach  (LEG) 

Subfunction 

COMBIMAN 

Seat  Posture  Initialization  (SIT) 

Subfunction 

COMBIMAN 

131 


Display  (DSP) 

Subfunction 

Both 

Geometry  Input  (CCI) 

Subfunction 

Both 

Enfleshment  (ENF) 

Subfunction 

Both 

Mobility  (MOB) 

Subfunction 

Both 

Enfleshment  Input  (RED) 

Subfunction 

Both 

Figure  18.  Function/Subfunction  List 


4.5.7  User-Computer  Interface 

Paragraph  3. 3. 7. 7  of  the  SOW  requires  that  all  versions  of  CREW  CHIEF  and 
COMBIMAN  software  be  in  compliance  with  Paragraph  5.15  (User-Computer  Interface)  of 
MIL-STD- 1 472D. 

Standard  procedures  for  each  user  interface  were  followed.  These  procedures  were 
set  by  UDRI  and  the  Air  Force.  In  defining  the  procedures,  all  prompts  for  CREW  CHIEF 
and  COMBIMAN  were  standardized.  The  terminology  was  set  for  key  words  in  the  prompts. 
These  key  words  include  DEFINE,  KEY,  PICK,  and  SELECT.  Simple  menus  are  used  to 
simplify  the  use  on  each  CAD  system.  Icons  are  used  if  possible.  At  present,  the  CAD  AM 
version  of  CREW  CHIEF  and  COMBIMAN  have  icons  incorporated  into  the  interfaces. 

On-line  help  is  available  on  most  of  the  CAD  systems  we  have  interfaced  to.  A  user's 
guide  is  available  for  each  CREW  CHIEF  and  COMBIMAN  interface  to  a  specific  CAD 
system.  Each  of  the  user's  guides  use  a  PROMPT,  ACTION,  RESULT  format.  The  location 
of  each  prompt  and  menu  on  the  screen  is  given  for  each  CAD  system. 

4.6  Configure  Software  for  Distribution 

Paragraph  3.3.8  of  the  SOW  requires  that  software  be  configured  for  distribution  by 
customizing  it  to  the  recipient's  configuration  to  the  degree  possible  and  that  copies  for 
distribution  be  produced.  All  configured  distribution  media  were  produced  upon  request  from 
AL/CFHD  or  the  CSERIAC  program  office.  Each  configured  distribution  media  was 
delivered  to  AL/CFHD  or  the  CSERIAC  program  office  for  distribution. 
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Distribution  Configurations 

One  hundred  twenty-three  copies  of  COMBIMAN  and  CREW  CHIEF  were 
distributed  during  the  course  of  this  contract.  COMBIMAN  and  CREW  CHIEF  have  been 
delivered  in  21  different  configurations.  The  configurations  comprise  seven  hardware 
platforms,  nine  CAD/graphics  systems,  three  versions  of  COMBIMAN  and  three  versions  of 
CREW  CHIEF  Thirteen  of  these  configurations  are  obsolete  and  are  no  longer  distributed. 


Obsolete  Configurations 

Eleven  of  the  COMBIMAN  and  CREW  CHIEF  configurations  are  no  longer 
distributed  because  of  obsolescence.  The  following  table  lists  these  configurations. 
The  table  shows  the  number  of  copies  distributed  on  this  contract.  The  last  column  of 
the  table  shows  the  obsolete  feature. 

Table  9.  COMBIMAN  and  CREW  CHIEF  Obsolete 
Configurations 

CREW  CHIEF 


Configuration 

Number  of  Copies 

Obsolete  Feature 

ComputerVision 

11 

CREW  CHIEF  Version 

CADDStation 

1.1 

ComputerVision  CV4001 

1 

CREW  CHIEF  Version  1 

and  obsolete  hardware 

System  Independent 

6 

CREW  CHIEF  Version  2 

FORTRAN  77 

System  Independent 

1 

CREW  CHIEF  Version  1 

FORTRAN  66 

CAD  AM  20  -  MVS 

3 

Obsolete  CAD  System 

CADAM  21  -  MVS 

17 

CREW  CHIEF  Version  2 

CAD  AM  21  -  VM/CMS 

1 

CREW  CHIEF  Version  1 

CADAM  21  -  VM/CMS 

4 

CREW  CHIEF  Version  2 

CADAM  21  -  VM/CMS 

2 

Obsolete  hardware 

CREW  CHIEF  V3 

133 


COMBIMAN 


Configuration 
Standalone  Version  7 

Standalone  Version  8 


Number  of  Copies 

1 

3 


Obsolete  Feature 

Obsolete  graphics 
software 

Obsolete  graphics 
software 


Current  Configurations 
CREW  CHIEF 


Currently,  CREW  CHIEF  is  available  on  five  platforms.  The  interfaces 
represent  three  CAD  systems  on  four  hardware  platforms.  The  CAD  systems  are 
CAD  AM,  CATIA,  and  I-DEAS.  The  hardware  platforms/operating  systems  are  IBM 
4341/MVS,  IBM  RS6000/AIX,  Silicon  Graphics  Personal  Iris/IRIX,  and  Sun  4/330 
SPARCstation/SUNOS.  The  following  table  shows  the  CAD  system,  operating 
system,  and  total  number  of  copies  of  CREW  CHIEF  V3  shipped. 


Table  10.  COMBIMAN  and  CREW  CHIEF  Current  Configurations 
OS _ CAD  System _ Total  Copies 


MVS 

CAD  AM  21 

2 

MVS 

CATIA 

9 

AIX 

CATIA 

24 

IRIX 

I-DEAS  LEVEL  V 

5 

SUNOS 

I-DEAS  LEVEL  VI 

1 
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COMBIMAN 

Currently,  COMBIMAN  is  available  on  six  platforms.  The  interfaces  represent 
three  CAD  systems  on  four  hardware  platforms.  The  CAD  systems  are  CAD  AM, 
CATIA,  and  I-DEAS.  The  hardware  platforms/operating  systems  are  IBM 
4341/MVS,  IBM  RS6000/AIX,  Silicon  Graphics  Personal  Iris/IRIX,  and  Sun  4/330 
SPARCstation/SUNOS.  The  following  table  shows  the  CAD  system,  operating 
system,  and  total  number  of  copies  of  COMBIMAN  V9  distributed. 


OS 

CAD  Svstem 

Total  Copies 

MVS 

CAD  AM  21 

1 

MVS 

CATIA 

7 

AIX 

CATIA 

14 

IRIX 

I-DEAS  Level  V 

4 

IRIX 

I-DEAS  Level  VI 

2 

SUNOS 

I-DEAS  Level  VI 

1 

4.7  Develop  User  and  Programmer  Instructions 

Because  of  the  complexity  of  the  CREW  CHIEF  and  COMBIMAN  systems  of 
programs,  comprehensible  instructions  for  the  user  and  the  developer  are  critical.  These 
instructions  must  be  tailored  to  each  individual  CAD  host,  and  must  be  updated  and  modified 
as  newer  versions  of  each  program  become  available. 

4.7.1  Develop  Instructions  for  Users  of  CREW  CHIEF  and  COMBIMAN 

During  this  contract,  UDRI  submitted  User's  guides  for  COMBIMAN,  Versions  9  and 
10,  and  for  CREW  CHIEF,  Versions  3  and  4.  In  addition,  CAD-specific  CREW  CHIEF 
User's  Guides  were  developed  and  submitted  for  CAD  AM  V2R21,  CATIA  V3,  and  I-DEAS 
level  V  and  VI.  For  COMBIMAN,  CAD-specific  user's  guides  were  developed  for  CATIA 
V3  and  I-DEAS  level  V. 
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The  user's  guide  for  CREW  CHIEF  Version  4  was  re-designed  to  incorporate  some  of 
the  suggestions  of  the  CREW  CHIEF  users.  It  now  comprises  three  volumes.  Volume  1 
provides  the  user  with  information  on  using  CREW  CHIEF  on  a  particular  CAD  system  (there 
will  be  several  volume  l's—  one  for  each  CAD  host). 

Volume  2  is  in  prompt-action-example-result  format,  and  provides  a  full  explanation  of 
each  possible  execution  option  in  the  programs.  Included  in  this  format  is  a  tutorial  that 
allows  the  novice  user  to  learn  how  to  use  most  of  the  major  analysis  tools.  The  second  half 
of  this  volume  is  a  quick-reference  guide. 

Volume  3  contains  descriptions  of  model  development  for  every  major  computer 
model  used  in  the  programs.  It  explains  the  theoretical  basis  of  each  model,  and  contains 
usage  notes  which  give  the  user  instructions  on  when  each  analysis  is  appropriate,  and  when 
to  select  various  options  for  a  particular  analysis. 

4.7.2  Develop  Instructions  for  Programmers  of  CREW  CHIEF  and  COMBIMAN 

The  SOW  required  the  expansion  of  the  programmer  instructions  for  COMBIMAN 
and  CREW  CHIEF  for  future  contract  programmers.  Contract  me  :ion  P00020,  deleted 
this  requirement  from  the  contract. 

4.7.3  Enhance  Instructions 

UDRI  enhanced  the  installation  instructions  for  CREW  CHIEF,  to  make  them  more 
comprehensible.  A  customer.  Structural  Dynamics  Research  Corporation  (SDRC),  reported  a 
problem  during  CREW  CHIEF  installation.  SDRC  was  attempting  to  install  Version  3  CREW 
CHIEF  for  the  I-DEAS  Level  VI  CAD  system  on  the  SUNOS  operating  system.  Consultation 
with  SDRC  personnel  determined  that  the  problem  was  due,  in  part,  to  a  lack  of  clarity  in  the 
instructions.  The  enhancements  to  the  installation  instructions  also  reflect  changes  to  the 
installation  process. 

SDRC  encountered  a  problem  installing  CREW  CHIEF.  They  installed  CREW 
CHIEF  on  one  of  their  Sun  SPARCstations.  The  installation  procedure  completed  without 
reporting  an  error.  However,  the  CREW  CHIEF  program  aborted  when  executed. 
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Upon  receipt  of  the  problem  report,  UDRI  attempted  to  reproduce  the  problem.  All 
attempts  at  installing  CREW  CHIEF  on  the  local  Sun  SPARCstation  were  successful.  UDRI 
then  consulted  with  the  SDRC  engineer  who  had  performed  the  CREW  CHIEF  installation.  It 
was  determined  that  the  CREW  CHIEF  program  was  aborting,  on  SDRC's  Sun,  because  it 
could  not  find  the  data  files.  The  installation  procedure  was  modified  to  avoid  this  problem. 

During  the  investigation  of  the  installation  problem,  it  became  apparent  that  the 
installation  instructions  made  some  incorrect  assumptions  about  the  Unix  experience  level  of 
the  installer.  These  assumptions  include  expecting  the  installer  to  have  all  necessary  Unix 
commands  in  their  search  path,  and  to  know  how  to  use  the  Unix  commands.  UDRI  changed 
the  installation  instructions  to  include  step  by  step  examples  of  every  Unix  command  required 
by  the  installer.  Also  added  were  instructions  detailing  how  to  start  the  CREW  CHIEF 
program,  because  many  installers  did  not  have  access  to  the  CREW  CHIEF  User's  Guide. 

4.8  Validation  and  Verification 

A  validation- Verification  process  was  run  for  each  modification  or  new  function  of 
COMBEMAN  and  CREW  CHIEF.  Depending  on  the  type  of  modification,  up  to  three  areas 
of  development  may  need  to  be  validated  or  verified.  In  all  cases,  verification  of  the  software 
was  performed.  Whenever  a  modification  or  enhancement  could  possibly  affect  the  contents 
of  a  database,  the  effects  of  the  modifications  or  enhancements  on  the  database  were 
specifically  verified.  Finally,  if  a  modification  or  enhancement  affected  a  mathematical  or 
statistical  model,  or  their  associated  software,  the  validity  and  output  of  these  models  were  re¬ 
checked. 

Software  verification  entails  verifying  all  aspects  of  input  and  output.  This  includes 
exercising  the  user  interface,  as  well  as  graphical  and  tabular  output. 

•  User  Input  Processing 

All  possible  combinations  of  user  input  for  affected  portions  of  the  software  were 
tested.  This  included  verification  of  program  interpretation  (did  the  core  receive  the  correct 
values  for  each  control  parameter?).  It  also  included  verification  of  processing  for  both  non¬ 
sensical  input,  as  well  as  input  that  fell  outside  the  range  of  the  models. 


137 


Software  Output 


• 

Both  the  graphical  and  tabular  outputs  were  checked.  This  included  consistency  of  the 
output  with  the  databases,  as  well  as  consistency  of  the  graphical  output  with  the  results  of  the 
analysis,  including  human  model  sizing,  posture,  and  strength.  It  also  included  verification  of 
the  function  log  output. 

Whenever  a  database  or  routines  accessing  a  database  were  modified  or  creating, 
UDRI  personnel  performed  verification  testing  on  the  output  from  the  databases.  In  many 
cases,  testing  involved  a  100%  verification  on  the  database  and  routines.  For  some  of  the 
larger  databases,  100%  verification  was  impractical,  so  only  subsets  were  verified.  The 
verification  subset  was  selected  to  ensure  that  all  code  and  database  changes  were  fully 
exercised. 

Any  new  or  modifications  to  existing  mathematical  computer  models  were  thoroughly 
verified  and  validated.  Verification  included  testing  the  model  for  expected  output,  especially 
with  regards  to  new  portions  of  code.  Proper  handling  of  special  cases  in  the  underlying 
mathematical  model  was  also  verified. 

Validation  was  performed  on  all  new  or  modifications  to  existing  mathematical 
computer  models.  Validation  cases  were  gleaned  from  various  sources,  including 
experimentation  and  existing  CAD  drawings.  Whenever  possible,  these  cases  were  selected  to 
ensure  that  the  modifications  or  additions  were  specifically  validated. 

For  each  verification/validation  effort,  a  specific  plan  was  submitted  to  the  Function 
Testing  and  Validation  Committee  for  comment  and  approval.  This  plan  included  a 
description  of  the  changes/modifications  being  tested,  as  well  as  a  description  of  which 
conditions  were  being  tested.  This  committee  also  had  to  give  final  approval  on  the  test 
results. 


4.9  Develop,  Acquire,  and  Maintain  Computer  Hardware  and  Software 

During  the  course  of  the  contract  UDRI  was  required  to  fabricate  and  modify  various 
research  equipment.  The  major  items  fabricated  and/or  modified  are  listed  below. 
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•  Designed  and  built  two  encoder/decoder  systems  for  use  in  automated  time  study 
data  collection. 

•  Horizontal  Time  Study  test  station,  with  multi-axis  adjustment  in  locations  and 
orientations  of  work,  and  with  large  and  small  access  openings 

•  Task  mounting  plate  and  weighted  boxes  for  use  in  the  TTE  experimentation 

•  Mounting  plates  and  clearance  barriers  for  use  in  the  TTE  experimentation 

•  Overhead  time  study  test  station,  with  multi-axis  locations  and  orientations  of 
work,  with  large  and  small  access  openings,  and  with  adjustable  ceiling  heights. 

•  Tool  clearance  barriers  for  use  in  TTE  experimentation 

•  Software  development  and  modification  to  allow  data  collection  and  analysis  for 
the  time  studies. 

In  addition,  while  this  contract  did  not  allow  direct  purchase  of  ADPE,  UDRI 
personnel  developed  requirements  and  performed  evaluations  for  several  computer 
upgrades/acquisitions,  including: 

•  Upgrade  of  the  IBM  mainframe  in  the  HESS  facility  (now  CWDEF). 

•  Replacement  of  the  IBM  mainframe  in  the  HESS  facility  with  an  RS6000/580 

•  Acquisition  of  4  X-terminals  to  be  used  for  development  of  the  human  models 

•  Acquisition  of  an  electromagnetic  3-D  locating  device  called  the  Flock  of  Birds 

•  Acquisition  of  a  low-cost  head-mounted  display  for  use  in  the  prototype  VR 
human  model. 

•  Acquisition  of  a  movie  camera  to  be  used  as  a  low-cost  RGB-NTSC  scan 
convertor. 

•  Acquisition  of  a  buffer  plotter  for  use  on  the  RS6000/580 

•  Acquisition  of  the  RS6000/320  on-loan  from  IBM 

•  Acquisition  of  the  Sun  SPARCstation  II  on-loan  from  Sun  Microsystems 

•  Acquisition  of  the  SG  Personal  Iris  on-loan  from  Silicon  Graphics 
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SECTION  5  -  ERGONOMICS  RESEARCH 


The  contract  SOW  requires  UDRI  to  perform  ergonomics  research  into  human 
physical  characteristics.  Sometimes,  these  data  exist  in  the  literature,  so  UDRI  must  review 
existing  literature  for  new  data  sources  and,  once  found,  acquire  and  catalog  these  data 
sources  into  the  ergonomics  research  library  maintained  on-site.  Because  the  ergonomics  data 
often  needed  for  CREW  CHIEF  and  COMBIMAN  are  often  non-existent  or  inappropriate, 
much  of  the  data  used  in  these  models  must  be  collected  via  experimentation.  This 
experimentation  must  be  well-planned  to  be  both  effective  and  safe  for  the  subjects.  And 
sometimes  additional  hardware  and  software  must  be  acquired  or  fabricated. 

5.1  Perform  Ergonomics  Research 

During  this  contract  period  UDRI  performed  extensive  research  in  support  of  the  Task 
Time  Estimator  and  the  CREW  CHIEF  human  model.  The  majority  of  the  research  studies 
conducted  during  this  contract  were  time  studies  performed  to  collect  data  for  the  Task  Time 
Estimator  (TTE).  UDRI  also  performed  ergonomic  research  to  collect  body  posture  data  to 
improve  the  fidelity  of  the  CREW  CHIEF  human  model  in  positioning  the  body  during  lifting 
and  carrying  task. 

Time  Study  Research.  UDRI  planned  and  conducted  numerous  time  and  motion 
studies  during  this  contract  employing  nearly  500  subjects  logging  over  1100  hours  of  actual 
data  collection.  Our  time  study  research  utilized  simulated  workstations  which  represent  the 
uniqueness  of  aircraft  maintenance,  such  as  limitation  on  physical  and  visual  accessibility, 
unusual  and  awkward  postures,  and  the  tools  needed  to  accomplish  aircraft  maintenance 
tasks.  UDRI's  time  studies  involving  the  effects  of  physical  accessibility  on  the  time  to 
remove  and  replace  aircraft  components,  have  included  limitations  due  to  access  opening  size, 
access  opening  location,  limited  hand  clearance  limited  hand  with  tool  clearance,  interference 
from  barriers,  interference  from  the  work  object,  and  the  location  of  work  (this  includes 
distance  from  access  opening,  angle  in  respect  to  access  opening,  and  orientation  of  the 
object).  UDRI's  time  and  motion  studies  involving  visual  accessibility  include  visual 
obscurations  due  to  access  opening  size,  the  work  object,  object  and  the  workers  hands  and 
arms.  UDRI  has  also  studied  the  interaction  between  physical  and  visual  access  and  how  they 
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are  effected  by  awkward  postures  common  to  flightline  maintenance  (reaching  overhead, 
reaching  at  arms  length,  hunched  down,  lying  flat,  and  lying  reaching  up  in  a  half  sit-up 
posture).  Our  studies  have  included  the  use  of  hands  alone,  and  all  combination  of  one  and 
two  ratchet,  box-end,  and  open  end  wrenches.  We  also  studied  the  effects  of  object  weight 
and  the  number  of  people  performing  a  task.  All  studies  involved  both  remove  and  replace 
activities.  The  focus  of  the  time  and  motion  research  performed  by  UDRI  thus  far  has  been 
on  the  validation  of  the  existing  data  and  the  collection  of  additional  data  for  the  development 
of  time  prediction  equations  to  reflect  flightline  conditions.  In  addition  to  performing  research 
on  variables  which  effect  maintenance  time,  UDRI  has  also  performed  several  studies  on  the 
time  study  method  itself.  These  studies  involved  the  effects  of  practice  and  pace  on  time 
study  results. 

Physical  Ergonomics  Research.  All  of  the  physical  ergonomics  research  involving 
human  strength  that  was  performed  in  the  Physical  Ergonomics  Laboratory,  also  included  the 
measurement  of  body  posture  during  strength  exertion  via  a  3-D  sonic  digitizing  system. 
However,  research  performed  offsite  by  our  sub-contractors  involving  strength  for  lifting  and 
carrying  tasks  did  not  include  body  posture  data.  The  reason  body  posture  data  were  not 
collected  during  these  studies  is  the  dynamic  nature  of  lifting  and  carry  task.  The  sonic 
digitizer  used  to  measure  body  posture  was  not  able  to  measure  the  body  in  motion. 

Therefore,  during  this  contract  period  UDRI  recreated  the  conditions  under  which  the  original 
research  was  performed  and  asked  subjects  to  remain  motionless  at  the  beginning  and  end  of 
the  lifting  and  carrying  tasks  to  allow  the  sonic  digitizer  to  measure  their  body  posture. 

During  the  body  posture  studies,  subjects  did  not  lift  or  carry  objects  of  any  significant  weight. 
The  objects  were  the  same  size  as  in  the  original  studies  but  contained  no  weights.  This  was 
done  to  allow  the  subjects  to  remain  motionless  long  enough  to  collect  the  necessary  posture 
data,  and  to  avoid  possible  injury  to  the  subjects. 

5.2  Develop  and  Acquire  Laboratory  Equipment 

UDRI  designed  and  fabricated,  modified,  and  purchased  several  pieces  of  equipment 
to  support  the  research  conducted  in  the  Physical  Ergonomics  Laboratory.  Whenever  possible 
we  used  the  Air  Force  furnished  shop  facilities  located  in  the  Ergonomics  laboratory  to 
fabricate  and  modify  research  equipment.  The  pieces  of  equipment  that  were  designed  and 
fabricated  were  two  Maintenance  Task  Simulators,  and  tone  encoder/decoder  devices  used  for 
task  time  data  collection.  Modifications  were  made  to  the  Tool  Torque  Strength  measuring 
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device,  the  Push/Pull  Static  strength  device,  and  the  visual  accessibility  apparatus.  Equipment 
purchases  included  a  camcorder,  a  video  cassette  recorder,  a  video  monitor,  (and  all  the  VR 
stuff). 


Maintenance  Task  Simulators.  UDRI  designed  and  fabricated  two  Maintenance 
Task  Simulators,  one  for  task  where  the  subjects  assume  a  vertical  posture,  and  one  where 
subjects  perform  simulated  maintenance  task  overhead.  Both  maintenance  task  simulators  are 
used  to  simulate  obstacles  in  the  maintenance  workplace  for  measuring  the  time  required  to 
perform  remove/replace  actions  of  varying  physical  demands.  The  vertical  type  apparatus 
consists  of  a  unistrut  framework  5.25  feet  wide,  8.5  feet  high,  and  6  feet  deep  on  a  wooden 
platform  8  feet  wide  and  10.5  feet  deep.  The  front  of  the  framework  is  a  plywood  barrier  with 
an  opening  through  which  the  subject  works  with  hand  tools  on  simulated  remove/replace 
tasks.  The  opening  is  of  different  sizes  to  vary  the  accessibility,  from  19.5  inches  square  down 
to  8  by  5  inches  square.  Inside  the  framework  (beyond  the  barrier)  is  an  adjustable  frame 
which  creates  vertical  and/or  horizontal  obstacles  around  which  the  subject  must  reach  while 
performing  the  task.  Beyond  the  obstacle  barrier  is  an  adjustable  mounting  surface  to  which 
the  experimental  objects  (of  various  kinds,  sizes  and  weights)  are  attached.  The  mounting 
surface  can  be  adjusted  from  28  to  65  inches  above  the  standing  surface  and  30  inches  left  or 
right  of  the  opening  of  the  plywood  barrier,  and  can  be  oriented  either  vertically  or 
horizontally.  The  plywood  barrier  extents  to  the  floor  and  prevents  tools  or  objects  from 
striking  the  subject  if  the  subject  should  accidentally  drop  any. 

The  overhead  type  is  based  on  a  wooden  platform,  4  by  8  foot.  It  simulates 
maintenance  actions  as  would  be  found  working  under  a  wing  or  under  a  fuselage.  A  unistrut 
structure  sits  above  the  platform.  The  height  of  the  plywood  ceiling  can  be  adjusted  from  12 
inches  to  6  feet  above  the  platform.  In  the  plywood  ceiling  there  is  a  19.5  by  19.5  inch 
opening.  Another  piece  of  plywood  with  a  5  by  8  inch  opening  in  it  can  be  placed  over  the 
larger  opening  to  restrict  access.  Directly  above  the  opening  there  is  the  mounting  structure 
for  the  experimental  object. 

Each  of  the  Maintenance  Task  Simulators  have  been  modified  several  times  to 
accommodate  the  experimental  conditions  and  objects  used  to  simulate  the  maintenance  task 
being  studied.  Those  modifications  include  the  addition  of  interference  barriers,  nut  plates 
with  changeable  self-locking  nuts,  and  a  flange  type  pipe  fitting. 
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Tone  Encoder/Decoder.  UDRI  designed  and  fabricated  two  tone  encoder/decoder 
devices.  This  device  was  used  in  the  time  study  research  to  automate  the  entry  of  task  time 
data.  The  encoder/decoder  permits  the  experimenter  to  superimpose  tones  onto  the  audio 
track  of  a  video  tape  with  a  hand  held  switch.  Four  separately  distinguishable  tones  can  be 
placed  on  the  tape  to  signal  the  beginning  and  end  of  task  elements,  and  other  task  events 
defined  for  a  particular  study.  Also  connected  to  the  encoder/decoder  device  is  a  start-stop 
button  which  the  subject  can  use  to  place  a  tone  on  the  tape  signaling  the  beginning  and  end  of 
each  task.  After  data  collection,  the  tape  containing  the  tones  is  played  back  through 
encoder/decoder  device  into  a  personal  computer.  The  computer  calculates  the  time  between 
the  tones  and  differentiates  between  the  4  different  tones.  This  data  are  then  stored  on  disk 
for  analysis. 

Equipment  Modifications.  UDRI  made  some  minor  modifications  to  the  Tool 
Torque  Strength  measuring  device,  the  Push/Pull  Static  strength  device,  and  the  visual 
accessibility  apparatus.  Modifications  to  the  Tool  Torque  Strength  measuring  device  included 
using  a  programmable  power  supply  to  control  the  resistance  of  an  electronic  brake.  Through 
a  feedback  loop  programmed  from  a  personal  computer  the  tool  torque  device  was  able  to 
simulate  the  tightening  of  a  bolt,  as  the  wrench  was  turned,  the  resistance  increased.  Another 
modification  included  the  addition  of  simulated  pieces  of  equipmer  h  are  torqued  by 

hand  rather  than  by  a  wrench. 

Modifications  to  the  Push/Pull  Static  strength  device  included  the  installation  of  a  shelf 
used  in  the  lift  posture  studies,  the  installation  of  a  ceiling  height  barrier  used  in  the  carry 
posture  study,  and  the  installation  of  anchors  used  to  hold  a  gurney  which  subjects  were 
required  to  reach  over  in  a  study  to  simulate  patient  handling  in  a  hospital. 

Modification  to  the  visual  accessibility  apparatus  included  replacing  the  LED  display 
with  a  constant  light  source.  This  modification  was  made  for  a  study  which  measured 
peripheral  vision. 

Equipment  Purchases.  UDRI  purchased  a  Sharp  camcorder,  a  Sony  video  cassette 
recorder,  and  a  Zenith  video  monitor.  This  equipment  was  used  as  part  of  the  data  collection 
and  editing  system  in  the  task  time  studies. 
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5.3  Maintain  Ergonomics  Library 


Reorganization  of  library 

•  The  library  was  re-categorized. 

The  library  contains  technical  reports,  text  books,  reference  books,  unpublished 
reports  and  software  manuals  from  outside  sources. 

-  It  was  decided  that  to  organize  the  library  for  more  efficient  use,  different 
categories  should  be  used.  The  document  types  were  reviewed  and  the 
following  categories  were  chosen:  000-099  COMBIMAN  and  CREW 
CHIEF  TRs  and  Supporting  Studies,  100-199  Anthropometry,  200-299 
Standards  and  Regulations,  300-399  Human  Modeling,  400-499  Computer 
Systems,  500-599  Space,  600-699  Human  Factors,  700-799  Mathematics, 
and  800-999  Miscellaneous.  The  documents  were  divided  into  the  various 
categories,  but  have  not  been  renumbered  (manually  or  in  the  computer). 

•  Before  more  effort  is  put  into  this  endeavor,  a  decision  needs  to  be  made  as  to 
whether  the  existing  library  system  is  kept  or  other  available  systems  are 
investigated.  The  current  library  system  is  Cardfile. 

Under  Cardfile,  there  are  seven  fields  to  input  information.  They  are  title  (225 
characters),  author(s)  (35  characters  per  name),  document  type  (5  characters), 
date  (8  characters),  report  number  (15  characters),  library  document  number  (15 
characters),  and  key  words  (15  characters  per  word). 

•  If  the  decision  is  made  to  keep  the  present  system,  old  documents  need  to  be 
renumbered  and  input  into  the  computer.  When  inputting  into  the  computer, 
document  summary  information  should  include  key  words  or  subject  matter. 
Numbers  (stickers)  need  to  be  placed  on  the  spine  of  each  document. 

-  New  documents  need  to  be  numbered  and  input  into  the  computer.  These 
documents  also  need  to  be  numbered  by  stickers.  If  check-out  cards  are 
used,  they  need  to  be  typed  and  the  card  holders  need  to  be  attached  to 
each  document. 
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-  A  new  check-out  system  needs  to  be  established.  Possibilities  include  8- 
1/2  x  11  size  folders  with  space  for  title,  date  of  check  out  and  person's 
name  or  a  card  system. 

-  Employees  need  to  be  informed  of  how  to  locate  documents  (on  computer) 
in  library.  There  should  be  a  use  and  rules  booklet,  which  includes 
instructions  explaining  how  to  search  the  library  database  for  a  specific 
item.  Also  included  should  be  a  description  of  library  procedures  on  the 
check-out  and  return  of  items.  The  individual  responsible  for  the  library 
should  be  the  only  person  with  editing  access  to  the  program. 

•  A  current  listing  of  all  documents  in  the  library  needs  to  be  compiled  and  kept  up- 
to-date.  This  listing  should,  if  possible,  be  accessed  by  author  name,  title  of 
document,  or  subject  matter.  A  hard  copy  should  be  made  available  in  the 
basement  office  and  also  in  the  library  itself. 

5.4  Plan  Research  Plan 

The  CREW  CHIEF  Research  Program  Plan  contains  four  volumes  each  relating  to  a 
specific  area  of  research  and  development  for  the  enhancement  of  the  CREW  CHIEF  human 
model  capabilities.  Volume  1  describes  the  plan  for  the  development  of  the  Task  Time 
Estimator.  Volume  2  describes  the  method  for  developing  a  space  maintenance  technician 
model.  Volume  3  describes  proposed  enhancements  to  the  human  model  interface.  Volume  4 
describes  proposed  program  enhancements.  The  following  is  a  brief  summary  of  each  of  the 
four  research  program  plan  volumes. 

Volume  I:  Task  Time  Estimator 

The  intended  purpose  of  the  CREW  CHIEF  Task  Time  Estimator  (TTE)  is  to  provide 
the  aircraft  designer  and  the  maintainability  engineer  with  a  means  of  predicting  the  time  for  a 
maintenance  task  from  a  conceptual  or  developmental  design.  The  development  of  this 
system  requires  research  into  a  variety  of  elements.  All  factors  that  may  significantly  affect 
time  to  complete  a  REMOVE/REPLACE  task  must  be  identified.  User  interfaces  must  be 
developed  for  integrating  a  Task  Time  Estimator  into  CREW  CHIEF  and,  further,  a  method 
must  be  devised  for  the  program  to  determine  different  levels  of  physical  accessibility.  Finally, 
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UDRI  must  determine  the  studies  that  will  be  required  to  build  an  appropriate  database  for  the 
Task  Time  Estimator.  The  Task  Time  Estimator  Research  Program  Plan  contains  guidelines 
for  the  TTE  development,  results  of  time  study  research,  description  of  proposed  research, 
methods  for  developing  the  TTE  databases,  description  of  the  TTE  database  structure, 
description  of  how  the  TTE  will  be  implemented,  and  a  plan  for  validating  the  time-to-repair 
estimated  computed  by  the  TTE. 

Volume  2:  Space  Maintenance  Technician  Model 

The  work  outlined  in  the  research  program  plan  for  the  Space  maintenance  technician 
model  is  designed  to  study  and  define  the  maintenance  tasks  that  are  likely  to  be  performed  in 
a  space  environment,  and  to  develop  a  practical  Space  Maintenance  Technician  Model  with 
appropriate  personal  protective  equipment  and  tools  to  perform  the  various  tasks. 

The  program  plan  addresses  the  development  of  a  plan  to  identify  the  specific  data 
which  must  be  gathered  to  support  the  model;  the  development  of  models  of  these  data;  the 
validation  of  models,  tasks,  space  suits,  and  tools;  a  description  of  how  these  can  be 
incorporated  into  CREW  CHIEF;  and  the  method  to  validate  the  enhanced  capability.  Also 
addressed  is  the  development  of  preliminary  models  of  the  "shuttle  space  suit"  and  model 
descriptions  of  current  "space  tools"  into  the  CREW  CHIEF  model. 

Many  of  the  techniques  used  in  developing  CREW  CHIEF  are  directly  transferable  to 
the  Space  Maintenance  Technician.  The  CREW  CHIEF  program  code  is  structured  in  such  a 
manner  that  it  may  be  directly  interfaced  with  virtually  any  CAD  system  available  on  the 
commercial  market  today.  It  was  designed  specifically  with  that  purpose  in  mind,  and 
performs  all  its  modeling  computations  in  a  central  core  which  is  devoid  of  any  CAD  system 
dependency.  All  CAD  system-dependent  subroutines  reside  outside  this  core,  and  need 
merely  to  be  replaced  with  their  counterparts  in  a  particular  CAD  system.  This  structure 
allows  any  aerospace  manufacturer  who  employs  a  3-D  CAD  system  to  use  the  CREW 
CHIEF  system  of  programs. 

Volume  3:  Interface-Related  Enhancements 

The  CAD  industry  is  veiy  volatile.  New  CAD  systems  are  constantly  being  introduced 
into  the  market,  while  old  CAD  systems  are  updated  and  enhanced.  User  preferences  on  CAD 
systems  also  shift,  as  do  even  the  types  of  geometric  entities  used  for  designing  systems.  And 
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there  are  many  enhancements  to  the  CREW  CHIEF-CAD  interface  that  naturally  arise  as  new 
techniques  are  developed,  both  in-house  and  in  the  literature. 


This  volume  of  the  Research  Program  Plan  deals  with  proposed  enhancements  to  the 
CREW  CHIEF-CAD  interfaces.  Some  of  these  enhancements  will  be  made  to  the  user 
interface,  and  are  included  because  they  were  suggested  by  current  users,  because  they  would 
greatly  simplify  the  task  of  interfacing  CREW  CHIEF,  or  because  they  would  significantly 
improve  the  usability  of  our  programs.  Other  enhancements  are  related  to  the  CAD  entities 
processed  by  CREW  CHIEF,  and  are  a  direct  result  of  the  typical  aerospace  CAD  designer 
progressing  from  wireframe  design  techniques  to  using  solids  and  surfaces  as  the  basis  for 
their  designs. 

The  proposed  enhancements  to  the  user  interface  can  be  classified  into  one  of  two 
types:  enhancements  requested  by  CREW  CHIEF  users,  and  enhancements  recommended  in- 
house.  One  of  the  major  suggestions  received  from  CREW  CHIEF  users  was  to  develop  the 
ability  to  allow  the  user  to  repeat  the  execution  of  a  CREW  CHIEF  function  while  changing 
only  a  few  of  the  parameters  needed  to  drive  that  function.  Users  also  requested  a  batch 
version  for  the  program  which  would  allow  users  to  perform  several  analyses  on  several 
candidate  designs  at  once.  Another  suggested  enhancement,  this  one  from  in-house,  is  the 
development  of  CAD  independent  help  pages  that  could  be  used  from  CAD  system  to  CAD 
system.  The  final  enhancement,  also  in-house,  is  the  development  of  a  PHIGS  (Programmer's 
Hierarchical  Graphics  Standard)  interface  to  CREW  CHIEF. 

When  the  CREW  CHIEF  CAD  Data  Interface  was  first  developed,  the  prevalent  3D 
entities  used  in  design  were  wireframe  in  nature;  almost  no  surfaces  or  solids  were  used. 
Consequently,  CREW  CHIEF  was  developed  to  process  these  types  of  entities,  and  only  basic 
surface  processing  was  performed.  Today,  however,  designers  make  extensive  use  of  solids 
and  surfaces,  ranging  from  simple  primitive  solids  (cones,  spheres,  etc.)  to  complex  Boundary 
Representation  solid  models.  Consequently,  the  CREW  CHIEF  entity  processing  needs  to  be 
expanded  to  include  full  surface  processing  (for  boundary  representation  models),  as  well  as 
processing  for  any  arbitrary  type  of  solid. 

Volume  4:  Program  Enhancements 

Aside  from  the  TTE  and  the  Space  Maintenance  Model,  UDRI  was  tasked  to  identify 
several  other  enhancements  for  the  CREW  CHIEF  program.  Suggestions  were  culled  from 
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users  and  from  in-house,  and  the  most  requested  enhancements  still  within  the  scope  of  the 
contract  were  selected.  Some  of  these  enhancements  will  be  transparent  to  the  CREW 
CHIEF  user,  because  they  deal  with  internal  program  structure  and  capabilities.  Others, 
though,  pertain  directly  to  CREW  CHIEF  functionality,  and  thus  will  be  readily  apparent  to 
the  CREW  CHIEF  user. 

1 .  GENERAL  PROGRAM  ENHANCEMENTS:  These  enhancements  deal 
specifically  with  internal  capabilities  and  structures,  and  relate  to  configuration  management  of 
the  CREW  CHIEF  program.  The  first  enhancement  discussed  is  the  development  of  a 
geometry  input  function,  which  will  speed  up  program  execution  in  general  by  preprocessing 
all  the  CAD  conversions  from  complex  geometric  entities  to  simpler  faceted  surfaces,  and  is 
necessitated  by  the  enhanced  surface  and  solids  processing  discussed  earlier.  Because  of  early 
coding  bias,  as  well  as  the  large  number  of  developers  on  the  CREW  CHIEF  program,  many 
modules  are  in  need  of  overhauling  so  that  other  enhancements  discussed  in  this  plan  can  be 
implemented  more  easily.  Finally,  the  set  of  subroutines  which  saves  and  restores  the  current 
human  model  data  has  grown  large  enough  and  complex  enough  to  warrant  the  creation  of  a 
new  subfunction  module,  the  Input/Output  Manager  subfunction. 

2.  FUNCTION  ENHANCEMENTS:  CREW  CHIEF  users  requested  several 
enhancements  to  the  analysis  functions.  Users  requested  two  additional  types  of  vision  plot,  a 
perspective  plot  and  an  orthographic  plot.  They  also  requested  that  the  Head  orientation  be 
modified  to  allow  direct  line-of-sight  viewing  of  the  target  point,  in  addition  to  the  more 
natural  orientation  used  currently.  Yet  another  requested  enhancement  was  the  ability  for  the 
human  model  to  use  more  than  one  tool  at  a  time  (  such  as  holding  a  nut  with  an  open  -end 
wrench,  while  tightening  the  attached  bolt  with  a  ratchet  wrench).  The  final  area  identified  as 
highly  desirable  by  users  is  animation,  for  visualization  and  training  purposes. 
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